Re: proposal: enable new error fields in plpgsql (9.4)
От | Pavel Stehule |
---|---|
Тема | Re: proposal: enable new error fields in plpgsql (9.4) |
Дата | |
Msg-id | CAFj8pRCd9YxBfTRYvtOpYV+kSSoXAeUXHpAhxsteJkWFxZU-5Q@mail.gmail.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 |
Hello 2013/7/2 Noah Misch <noah@leadboat.com>: > 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. > +1 Pavel > -- > Noah Misch > EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: