> As for the treading-on-user-namespace issue, we already do that for all
> implicitly created indexes (see UNIQUE, PRIMARY KEY, etc). I'd prefer
> to treat named constraints consistently with that long-established
> practice until we have a better idea that can be implemented uniformly
> across that whole set of constructs. (Once we have schemas, for
> example, it might be practical to give indexes a separate namespace
> from tables, which'd help a lot.)
Surely the best way to do it would be to make the unique and primary key
implicitly created indices totally invisible to the user. Or at least add a
'system' flag to their entries in the pg_indexes table. Create a
pg_constraint table instead that people can use to find constraints.
To support this, dropping unique and pk constraints would no longer be
possible (and _should_ no longer be possible) with a CREATE/DROP INDEX
command, and instead would be achieved with a functional ALTER TABLE
ADD/DROP CONSTRAINT statement.
This seems good in that in the future, the way pk's and uniques are
implemented may change (and no longer be indices for some reason), and any
changes will be invisible to the user.
And while we're at it, add not null and fk constraints to pg_constraint, and
make the fk triggers totally invisible to the user, for similar reasons.
I'm not sure what to do with check constraints - they seem fairly clearly
declared as it is...
Chris
