Re: operator exclusion constraints

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: Jeff Davis <pgsql(at)j-davis(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: operator exclusion constraints
Date: 2010-03-11 14:39:31
Message-ID: 19842.1268318371@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greg Stark <gsstark(at)mit(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2010-03-11 14:49:13 Re: Can we still trust plperl?
Previous Message Andrew Dunstan 2010-03-11 14:31:46 Can we still trust plperl?