Thread: Re: [COMMITTERS] pgsql/ oc/src/sgml/catalogs.sgml oc/src/sgml/r ...

Is it at all a problem that several columns in pg_conversion have the same
name as columns in pg_constraint?

Should the ones in pg_conversion become: convname instead of conname, etc.
simply for clarity?

Chris

----- Original Message -----

> Log message:
> Second phase of committing Rod Taylor's pg_depend/pg_constraint patch.
> pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY
> constraints all have real live entries in pg_constraint.  pg_depend
> exists, and RESTRICT/CASCADE options work on most kinds of DROP;
> however, pg_depend is not yet very well populated with dependencies.
> (Most of the ones that are present at this point just replace formerly
> hardwired associations, such as the implicit drop of a relation's pg_type
> entry when the relation is dropped.)  Need to add more logic to create
> dependency entries, improve pg_dump to dump constraints in place of
> indexes and triggers, and add some regression tests.
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>

"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
> Is it at all a problem that several columns in pg_conversion have the same
> name as columns in pg_constraint?
> Should the ones in pg_conversion become: convname instead of conname, etc.
> simply for clarity?

Perhaps so.  The two patches were developed independently and so no one
thought about it.  I don't have a strong feeling about which set of
names to change, although perhaps pg_conversion is referenced in fewer
places at the moment.

Tatsuo, any opinions?
        regards, tom lane