On 13 January 2013 06:13, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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

In response to

• Re: enhanced error fields at 2013-01-13 06:13:34 from Pavel Stehule

Responses

• Re: enhanced error fields at 2013-01-13 17:39:01 from Tom Lane

pgsql-hackers by date

Next:	From: Hannu Krosing	Date: 2013-01-13 10:49:27
	Subject: Re: logical changeset generation v3 - comparison to Postgres-R change set format
Previous:	From: Erik Rijkers	Date: 2013-01-13 10:17:31
	Subject: erroneous restore into pg_catalog schema