Thread: Clarification to catalog-pg-class
All, Currently, catalog-pg-class is a bit confusing as to where FKs are tracked in pg_class. Please update the lines for relchecks and reltriggers to read: relchecks int2 Number of check constraints on the table (but not other types of constraints); see pg_constraint catalog reltriggers int2 Number of triggers on the table, including constraint-triggers for foreign keys; see pg_trigger catalog --Josh Berkus
Josh Berkus wrote: > All, > > Currently, catalog-pg-class is a bit confusing as to where FKs are > tracked in pg_class. Please update the lines for relchecks and > reltriggers to read: > > relchecks int2 Number of check constraints on the table (but not > other types of constraints); see pg_constraint catalog Uh, why do we have to say "but" when we clearly say "check constraints"? Do we need to say "CHECK" contraints? > reltriggers int2 Number of triggers on the table, including > constraint-triggers for foreign keys; see pg_trigger catalog pg_class doesn't have that column anymore, it has relhastriggers. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce, >> Currently, catalog-pg-class is a bit confusing as to where FKs are >> tracked in pg_class. Please update the lines for relchecks and >> reltriggers to read: >> >> relchecks int2 Number of check constraints on the table (but not >> other types of constraints); see pg_constraint catalog > > Uh, why do we have to say "but" when we clearly say "check constraints"? > Do we need to say "CHECK" contraints? Because I've encountered two people on IRC (and a client) who were confused about this, and it confused me briefly when I fielded their questions. Saying "CHECK constraints" would also probably do it, or saying "check constraints (only)" BTW, why do we still have relukeys etc. around? If we haven't used them in 5 versions, shouldn't we purge them? > >> reltriggers int2 Number of triggers on the table, including >> constraint-triggers for foreign keys; see pg_trigger catalog > > pg_class doesn't have that column anymore, it has relhastriggers. Ah. Where are we tracking FKs at this point, then? --Josh
Josh Berkus wrote:
> Bruce,
>
> >> Currently, catalog-pg-class is a bit confusing as to where FKs are
> >> tracked in pg_class. Please update the lines for relchecks and
> >> reltriggers to read:
> >>
> >> relchecks int2 Number of check constraints on the table (but not
> >> other types of constraints); see pg_constraint catalog
> >
> > Uh, why do we have to say "but" when we clearly say "check constraints"?
> > Do we need to say "CHECK" contraints?
>
> Because I've encountered two people on IRC (and a client) who were
> confused about this, and it confused me briefly when I fielded their
> questions. Saying "CHECK constraints" would also probably do it, or
> saying "check constraints (only)"
Uppercase done, with <literal> tag.
> BTW, why do we still have relukeys etc. around? If we haven't used them
> in 5 versions, shouldn't we purge them?
Uh, that one is gone now:
Table "pg_catalog.pg_class"
Column | Type | Modifiers
----------------+-----------+-----------
relname | name | not null
relnamespace | oid | not null
reltype | oid | not null
relowner | oid | not null
relam | oid | not null
relfilenode | oid | not null
reltablespace | oid | not null
relpages | integer | not null
reltuples | real | not null
reltoastrelid | oid | not null
reltoastidxid | oid | not null
relhasindex | boolean | not null
relisshared | boolean | not null
relkind | "char" | not null
relnatts | smallint | not null
relchecks | smallint | not null
relhasoids | boolean | not null
relhaspkey | boolean | not null
relhasrules | boolean | not null
relhastriggers | boolean | not null
relhassubclass | boolean | not null
relfrozenxid | xid | not null
relacl | aclitem[] |
reloptions | text[] |
>
> >
> >> reltriggers int2 Number of triggers on the table, including
> >> constraint-triggers for foreign keys; see pg_trigger catalog
> >
> > pg_class doesn't have that column anymore, it has relhastriggers.
>
> Ah. Where are we tracking FKs at this point, then?
The count was only used to determine if we should check for triggers, so
we now use a boolean; the code checks are the same.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
> The count was only used to determine if we should check for triggers, so > we now use a boolean; the code checks are the same. Hmmm. In the beta publicity and release notes, we should warn tool designers about this. It's quite possible that some of them (SQLManger, etc.) were using the counts for something. No reason to surprise them. --Josh
Josh Berkus wrote: > > > The count was only used to determine if we should check for triggers, so > > we now use a boolean; the code checks are the same. > > Hmmm. In the beta publicity and release notes, we should warn tool > designers about this. It's quite possible that some of them (SQLManger, > etc.) were using the counts for something. No reason to surprise them. Well, we have never documented system table changes in any previous release, and never got a request to document them either. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian wrote: > Josh Berkus wrote: >> Bruce, >> >>>> Currently, catalog-pg-class is a bit confusing as to where FKs are >>>> tracked in pg_class. Please update the lines for relchecks and >>>> reltriggers to read: >>>> >>>> relchecks int2 Number of check constraints on the table (but not >>>> other types of constraints); see pg_constraint catalog >>> Uh, why do we have to say "but" when we clearly say "check constraints"? >>> Do we need to say "CHECK" contraints? >> Because I've encountered two people on IRC (and a client) who were >> confused about this, and it confused me briefly when I fielded their >> questions. Saying "CHECK constraints" would also probably do it, or >> saying "check constraints (only)" > > Uppercase done, with <literal> tag. This is inconsistent with the rest of the documentation.
Peter Eisentraut wrote: > Bruce Momjian wrote: > > Josh Berkus wrote: > >> Bruce, > >> > >>>> Currently, catalog-pg-class is a bit confusing as to where FKs are > >>>> tracked in pg_class. Please update the lines for relchecks and > >>>> reltriggers to read: > >>>> > >>>> relchecks int2 Number of check constraints on the table (but not > >>>> other types of constraints); see pg_constraint catalog > >>> Uh, why do we have to say "but" when we clearly say "check constraints"? > >>> Do we need to say "CHECK" contraints? > >> Because I've encountered two people on IRC (and a client) who were > >> confused about this, and it confused me briefly when I fielded their > >> questions. Saying "CHECK constraints" would also probably do it, or > >> saying "check constraints (only)" > > > > Uppercase done, with <literal> tag. > > This is inconsistent with the rest of the documentation. Should I use <emphasis>? <literal>? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian wrote: > Peter Eisentraut wrote: >> Bruce Momjian wrote: >>> Josh Berkus wrote: >>>> Bruce, >>>> >>>>>> Currently, catalog-pg-class is a bit confusing as to where FKs are >>>>>> tracked in pg_class. Please update the lines for relchecks and >>>>>> reltriggers to read: >>>>>> >>>>>> relchecks int2 Number of check constraints on the table (but not >>>>>> other types of constraints); see pg_constraint catalog >>>>> Uh, why do we have to say "but" when we clearly say "check constraints"? >>>>> Do we need to say "CHECK" contraints? >>>> Because I've encountered two people on IRC (and a client) who were >>>> confused about this, and it confused me briefly when I fielded their >>>> questions. Saying "CHECK constraints" would also probably do it, or >>>> saying "check constraints (only)" >>> Uppercase done, with <literal> tag. >> This is inconsistent with the rest of the documentation. > > Should I use <emphasis>? <literal>? <emphasis> would be appropriate, but I personally don't really buy the premise. If we had to highlight every idiosyncracy in the catalog fields, it would end up looking quite colorful. I suppose a more constructive point would be, where are the other constraint types kept track of?
Peter, > I suppose a more constructive point would be, where are the other > constraint types kept track of? AFAICT, we're not tracking them in pg_class at all anymore, except that FKs will set relhastrigger=true in the absensce of any other triggers. The confusion on this particular line is caused by the "see pg_constraint catalog", which covers *all* constraints, whereas relconstrains only counts the CHECK constraints and not other types. That's why I think a small emphasis on CHECK would prevent people from being confused again. Of course, at this point, we've spent more time discussing the issue than people have been confused by it, probably. --Josh