RE: [HACKERS] how to deal with sparse/to-be populated tables
От | Hiroshi Inoue |
---|---|
Тема | RE: [HACKERS] how to deal with sparse/to-be populated tables |
Дата | |
Msg-id | 000b01bf6ecc$d7733a60$2801007e@tpf.co.jp обсуждение исходный текст |
Ответ на | Re: [HACKERS] how to deal with sparse/to-be populated tables (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] how to deal with sparse/to-be populated tables
|
Список | pgsql-hackers |
> -----Original Message----- > From: owner-pgsql-hackers@postgreSQL.org > [mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Tom Lane > > Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> writes: > > Hmm. Doesn't PostgreSQL have a big list of error codes? I don't think > > it does, I've never seen one. There should be a way to get error > > codes without comparing strings. Should this be on the TODO? > > It doesn't, there should, and it already is ;-) > Doens't the following TODO imply it ? * Allow elog() to return error codes, not just messages Many people have complained about it. However,it seems not effective without a functionality of statement level rollback. AFAIK,Vadim has planed it together with savepoint functionality. Regards. Hiroshi Inoue Inoue@tpf.co.jp
В списке pgsql-hackers по дате отправления: