| From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
|---|---|
| To: | Stephen Frost <sfrost(at)snowman(dot)net> |
| Cc: | Peter Geoghegan <peter(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
| Subject: | Re: enhanced error fields |
| Date: | 2012-12-29 21:24:43 |
| Message-ID: | CAFj8pRDUN4bL-PZOWjJNzyYFwQDVZCsivNM9T-C8yzYiLa_KMg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
2012/12/29 Stephen Frost <sfrost(at)snowman(dot)net>:
> * Pavel Stehule (pavel(dot)stehule(at)gmail(dot)com) wrote:
>> it is a problem of this patch or not consistent constraints implementation ?
>
> 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.
can we remove CONSTRAINT_NAME from this patch? Minimally TABLE_SCHEMA,
TABLE_NAME and COLUMN_NAME works as expected.
CONSTRAINT_NAME can be implemented after constraints refactoring
Pavel
>
> Thanks,
>
> Stephen
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2012-12-29 21:30:53 | Re: enhanced error fields |
| Previous Message | Stephen Frost | 2012-12-29 21:15:21 | Re: enhanced error fields |