These work:
alter table books add constraint books_from_within check (books.from >=3D 5
and books.from < 11);
alter table books add constraint books_as_whitelist check (books.as in
('whitelisted1','whitelisted2','whitelisted3'));
These don't:
alter table books add constraint books_from_reference foreign key (from)
references authors (id) ;
alter table books add constraint books_as_unique unique (as);
The key being that the former are scoped by table while the latter are
standalone, and the parser doesn't allow scoping. However, the statement
itself has the table information, and AFAIK, these constraints are always
table-specific, so you should be able to check whether the column exists on
the table.
Basically, though the words are reserved, in the scope they're being used,
it seems they're unambiguous as to what use they're taking.
On Mon, Jan 4, 2010 at 5:36 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
> On m=E5n, 2010-01-04 at 03:48 +0000, Ben Woosley wrote:
> > However, unique and foreign key constraints added using the "alter
> > table add
> > constraint" syntax fail on the column name. At this point the
> > statement has
> > enough information (the host table name) to properly identify the
> > column
> > despite the unorthodox name. Alternatively, you could allow the .
> > syntax
> > qualification inside the argument to the constraint.
>
> Example please?
>
>