Re: proposal: enable new error fields in plpgsql (9.4)
От | Noah Misch |
---|---|
Тема | Re: proposal: enable new error fields in plpgsql (9.4) |
Дата | |
Msg-id | 20130702202200.GA996935@tornado.leadboat.com обсуждение исходный текст |
Ответ на | Re: proposal: enable new error fields in plpgsql (9.4) (Noah Misch <noah@leadboat.com>) |
Ответы |
Re: proposal: enable new error fields in plpgsql (9.4)
|
Список | pgsql-hackers |
On Fri, Jun 28, 2013 at 12:08:21PM -0400, Noah Misch wrote: > On Fri, Jun 28, 2013 at 05:21:29PM +0200, Pavel Stehule wrote: > > 2013/6/28 Noah Misch <noah@leadboat.com>: > > > Okay. I failed to note the first time through that while the patch uses the > > > same option names for RAISE and GET STACKED DIAGNOSTICS, the existing option > > > lists for those commands differ: > > > > > > --RAISE option-- --GET STACKED DIAGNOSTICS option-- > > > ERRCODE RETURNED_SQLSTATE > > > MESSAGE MESSAGE_TEXT > > > DETAIL PG_EXCEPTION_DETAIL > > > HINT PG_EXCEPTION_HINT > > > CONTEXT PG_EXCEPTION_CONTEXT > > > > > > To be consistent with that pattern, I think we would use COLUMN, CONSTRAINT, > > > TABLE, TYPE and SCHEMA as the new RAISE options. > > > > I understand to your motivation, but I am not sure. Minimally word > > "TYPE" is too general. I have not strong opinion in this area. maybe > > DATATYPE ?? > > I'm not positive either. DATATYPE rather than TYPE makes sense. Here's a revision bearing the discussed name changes and protocol documentation tweaks, along with some cosmetic adjustments. If this seems good to you, I will commit it. -- Noah Misch EnterpriseDB http://www.enterprisedb.com
Вложения
В списке pgsql-hackers по дате отправления: