Skip site navigation (1) Skip section navigation (2)

Re: enhanced error fields

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Geoghegan <peter(dot)geoghegan86(at)gmail(dot)com>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, "anarazel(at)anarazel(dot)de" <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Subject: Re: enhanced error fields
Date: 2013-01-29 04:08:33
Message-ID: 14942.1359432513@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
I wrote:
> Rather what we've got is that constraints are uniquely named among
> those associated with a table, or with a domain.  So the correct
> unique key for a table constraint is table schema + table name +
> constraint name, whereas for a domain constraint it's domain schema +
> domain name + constraint name.  The current patch provides sufficient
> information to uniquely identify a table constraint, but not so much
> domain constraints.  Should we fix that?  I think it'd be legitimate
> to re-use SCHEMA_NAME for domain schema, but we'd need a new nonstandard
> field DOMAIN_NAME (or maybe better DATATYPE_NAME) if we want to fix it.

I have hacked up the code (but not yet the documentation) to support
this, but I found out that there's at least one place where this
definition of the field semantics is a bit awkward.  The issue is that
this definition presupposes that we want to complain about a table or
a domain, never both, because we're overloading both the SCHEMA_NAME
and CONSTRAINT_NAME fields for both purposes.  This is annoying in
validateDomainConstraint(), where we know the domain constraint that
we're complaining about and also the table/column containing the bad
value.  We can't fill in both TABLE_NAME and DATATYPE_NAME because
they both want to set SCHEMA_NAME, and perhaps not to the same value.

Since the error report is about a domain constraint, I don't have a big
problem deciding that the domain has to win this tug-of-war.  And it
could easily be argued that if we had separate fields and filled in
both, an application could get confused about whether we meant a table
constraint or a domain constraint.  (As submitted, the patch would
definitely have made it look like we were complaining about a table
constraint.)  But it's still annoying that we can't represent all the
info that is in the human-readable message.

I'm not sure we should allow corner cases like this to drive the design;
but if anyone has an idea about a cleaner way, let's hear it.

			regards, tom lane


In response to

Responses

pgsql-hackers by date

Next:From: David RowleyDate: 2013-01-29 05:01:47
Subject: Re: Hm, table constraints aren't so unique as all that
Previous:From: Noah MischDate: 2013-01-29 03:48:37
Subject: Re: Re: Doc patch making firm recommendation for settingthe value of commit_delay

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group