Horton

Re: enhanced error fields

Pavel Stehule <pavel.stehule@gmail.com>

View thread
From: Pavel Stehule <pavel.stehule@gmail.com>
To: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Cc: Alvaro Herrera <alvherre@commandprompt.com>, Peter Geoghegan <peter@2ndquadrant.com>, Tom Lane <tgl@sss.pgh.pa.us>
Date: 2012-08-20T13:09:38Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Create a "sort support" interface API for faster sorting.

Attachments

Hello

here is updated patch - merge comments, docs, formatting, some
identifiers from Peter Geoghegan's patch

Regards

Pavel


2012/7/18 Pavel Stehule <pavel.stehule@gmail.com>:
> Hello
>
> * renamed erritem to err_generic_string
> * fixed CSVlog generation
> * new file /utils/error/relerror.c with axillary functions -
> declarations are in utils/rel.h
>
> Regards
>
> Pavel
>
> 2012/7/11 Tom Lane <tgl@sss.pgh.pa.us>:
>> Alvaro Herrera <alvherre@commandprompt.com> writes:
>>> FWIW about the new include:  I feel a strong dislike about the forward
>>> declaration you suggest.  Defining Relation in elog.h seems completely
>>> out of place.
>>
>> Agreed.  Maybe a reasonable solution is to allow some ereport helper
>> functions (or, really, wrappers for the helper functions) to be declared
>> someplace else than elog.h.  They'd likely need to be implemented
>> someplace else than elog.c, too, so this doesn't seem unreasonable.
>>
>> The generic helper function approach doesn't seem too unreasonable for
>> this: elog.h/.c would provide something like
>>
>>         err_generic_string(int fieldid, const char *str)
>>
>> and then someplace else could provide functions built on this that
>> insert table/schema/column/constraint/etc names into suitable fields.
>>
>>                         regards, tom lane