Re: proposal: enable new error fields in plpgsql (9.4)

On Fri, Jun 28, 2013 at 03:31:00PM +0200, Pavel Stehule wrote:
> Hello
>
> 2013/6/28 Noah Misch <noah(at)leadboat(dot)com>:
> > On Fri, Jun 28, 2013 at 07:49:46AM +0200, Pavel Stehule wrote:
> >> 2013/6/28 Noah Misch <noah(at)leadboat(dot)com>:
> >> > On Tue, Jun 25, 2013 at 03:56:27PM +0200, Pavel Stehule wrote:
> >> >> cleaned patch is in attachment
> >> >
> >> > Of the five options you're adding to GET STACKED DIAGNOSTICS, four of them
> >> > appear in the SQL standard. DATATYPE_NAME does not; I think we should call it
> >> > PG_DATATYPE_NAME in line with our other extensions in this area.
> >> >
> >>
> >> yes, but It should be fixed in 9.3 enhanced fields too - it should be
> >> consistent with PostgreSQL fields
> >
> > What else, specifically, should be renamed? (Alternately, would you prepare a
> > new version of the patch incorporating the proper name changes?)
>
> I looked to source code, and identifiers in our source code are
> consistent, so my comment hasn't sense. Yes, I agree, so only
> identifier used in GET DIAGNOSTICS statement should be renamed. So,
> only DATATYPE_NAME should be renamed to PG_DATATYPE_NAME.

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.

--
Noah Misch
EnterpriseDB http://www.enterprisedb.com