Re: SET CONSTRAINTS not schema-aware

from the prelim sql92 standard:

Syntax Rules

1) If a <constraint name definition> is contained in a <schema
def-
inition>, and if the <constraint name> contains a <schema
name>,
then that <schema name> shall be the same as the specified or
implicit <schema name> of the containing <schema definition>.

2) The <qualified identifier> of <constraint name> shall be
differ-
ent from the <qualified identifier> of the <constraint name>
of
any other constraint defined in the same schema.

Further along, talking about drop schema, it says:

4) Let A be the <constraint name> of any assertion contained in
S. The following <drop assertion statement> is effectively
exe-
cuted:

DROP ASSERTION A

S is the schema, so it would appear they do mean that constraints are
"contained" so to speak by a schema.

On Thu, 15 May 2003, Bruce Momjian wrote:

> Peter Eisentraut wrote:
> > Tom Lane writes:
> >
> > > Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > > > Tom Lane wrote:
> > > >> SET CONSTRAINTS still does what it used to do, which is to alter the
> > > >> behavior of all constraints with the given name. We should probably
> > > >> expand the syntax so that a particular table name can be mentioned.
> > >
> > > > Is this a TODO?
> > >
> > > Nobody objected to my statement, so I guess so ...
> >
> > I just hate to see us breaking the SQL standard for no technical reason.
>
> Does it actually break the standard of just extend it. I don't see any
> problem with extending it.
>
>