Re: enhanced error fields

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
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-30 14:37:30
Message-ID: 20121230143729.GM16126@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* Pavel Stehule (pavel(dot)stehule(at)gmail(dot)com) wrote:
> so - cannot be a solution define CONSTRAINT_TABLE field - constaint
> names in table are unique.

Adding a table column, and a schema column, would be ideal. Those would
all be part of the PK and not null'able, but then we wouldn't
necessairly always return all that information- that's the situation
that we've been talking about.

> sure there is a problem with long names, but I am thinking so it has
> solution - when constraint has no name, then we can try to generate
> name, and when this name is longer than 63 chars, then CREATE
> STATEMENT fails and users should be define name manually - this
> feature should be disabled by guc due compatibility issues.

CREATE doesn't fail if the name is too long today, it truncates it
instead. I continue to feel that's also the wrong thing to do.

Thanks,

Stephen

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2012-12-30 14:57:15 Re: enhanced error fields
Previous Message Dimitri Fontaine 2012-12-30 12:18:32 Re: Event Triggers: adding information