Re: operator exclusion constraints - Mailing list pgsql-hackers

From Tom Lane
Subject Re: operator exclusion constraints
Date
Msg-id 19842.1268318371@sss.pgh.pa.us
Whole thread Raw
In response to Re: operator exclusion constraints  (Greg Stark <gsstark@mit.edu>)
List pgsql-hackers
Greg Stark <gsstark@mit.edu> writes:
> There is a third option -- print PRIMARY keys twice, once as a btree
> index and again as a constraint where it says somehting like "USING
> index foo_pkey"

No, that's exactly what I hate about the current behavior for exclusion
constraints, and I'd like it even less for more-common options like
primary or unique constraints.  \d is too d*mn verbose already; there is
no percentage in making it even longer by printing redundant entries for
many indexes.

One thing I did think about was converting PK/UNIQUE indexes to be
printed by pg_get_constraintdef() too, rather than assembling an ad-hoc
output for them as we do now.  This would make the code a bit simpler
but would involve some small changes in the output --- in particular,
you wouldn't see any indication that they were btrees, since there's
no place for that in standard constraint syntax.  On balance it didn't
seem like an improvement, although it would partially respond to your
desire to have the output be cut-and-pasteable.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Can we still trust plperl?
Next
From: Kenneth Marshall
Date:
Subject: Re: Can we still trust plperl?