Re: proposal: enable new error fields in plpgsql (9.4) - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: proposal: enable new error fields in plpgsql (9.4)
Date
Msg-id CAFj8pRCd9YxBfTRYvtOpYV+kSSoXAeUXHpAhxsteJkWFxZU-5Q@mail.gmail.com
Whole thread Raw
In response to Re: proposal: enable new error fields in plpgsql (9.4)  (Noah Misch <noah@leadboat.com>)
Responses Re: proposal: enable new error fields in plpgsql (9.4)
List 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 by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Review: query result history in psql
Next
From: Josh Berkus
Date:
Subject: Re: [9.4 CF 1] The Commitfest Slacker List