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)  (Pavel Stehule <pavel.stehule@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Fujii Masao
Дата:
Сообщение: Re: Support for REINDEX CONCURRENTLY
Следующее
От: Robert Haas
Дата:
Сообщение: Re: preserving forensic information when we freeze