Re: 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(at)momjian(dot)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(at)momjian(dot)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(at)momjian(dot)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(at)momjian(dot)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