Horton

Re: enhanced error fields

Peter Geoghegan <peter@2ndquadrant.com>

View thread
From: Peter Geoghegan <peter@2ndquadrant.com>
To: Pavel Stehule <pavel.stehule@gmail.com>
Cc: Stephen Frost <sfrost@snowman.net>, Tom Lane <tgl@sss.pgh.pa.us>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>, Alvaro Herrera <alvherre@commandprompt.com>
Date: 2013-01-13T10:44:12Z
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.

On 13 January 2013 06:13, Pavel Stehule <pavel.stehule@gmail.com> wrote:
>> Not sure, but I don't think it matters.  You can blame the constraint
>> implementation, but that doesn't change my feelings about what we need
>> before we can accept a patch like this.  Providing something which works
>> only part of the time and then doesn't work for very unclear reasons
>> isn't a good idea.  Perhaps we need to fix the constraint implementation
>> and perhaps we need to fix the error information being returned, or most
>> likely we have to fix both, it doesn't change that we need to do
>> something more than just ignore this problem.
>
> so we have to solve this issue first. Please, can you do resume, what
> is and where is current constraint implementation raise
> strange/unexpected messages?

I felt that this was quite unnecessary because of the limited scope of
the patch, and because this raises thorny issues of both semantics and
implementation. Tom agreed with this general view - after all, this
patch exists for the express purpose of having a well-principled way
of obtaining the various fields across lc_messages settings. So I
don't see that we have to do anything about making a constraint_schema
available.

-- 
Peter Geoghegan       http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services