| From: | Rod Taylor <pg(at)rbt(dot)ca> |
|---|---|
| To: | Jan Wieck <JanWieck(at)Yahoo(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Richard Huxton <dev(at)archonet(dot)com>, Markus Bertheau <twanger(at)bluetwanger(dot)de>, Josh Berkus <josh(at)agliodbs(dot)com>, olly(at)lfix(dot)co(dot)uk, pgsql-sql(at)postgresql(dot)org, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
| Subject: | Re: multi column foreign key for implicitly unique columns |
| Date: | 2004-08-18 16:46:14 |
| Message-ID: | 1092847573.32799.148.camel@jester |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-sql |
On Wed, 2004-08-18 at 12:27, Jan Wieck wrote:
> On 8/18/2004 12:18 PM, Tom Lane wrote:
>
> > Richard Huxton <dev(at)archonet(dot)com> writes:
> >> * Allow multiple unique constraints to share an index where one is a
> >> superset of the others' columns.
> >
> >> That way you can mark it unique without having the overhead of multiple
> >> indexes.
> >
> > That just moves the uncertain-dependency problem over one spot, ie, it's
> > the fabricated unique constraint that you can't pin down the
> > requirements for.
>
> If we allow for a unique index, that
Silly question, but why does UNIQUE require an index at all? Yes,
current implementation does, and agreed that checks will be mighty slow
without an index (so are CASCADES to a non-indexed column)...
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2004-08-18 16:46:26 | Re: multi column foreign key for implicitly unique columns |
| Previous Message | Jan Wieck | 2004-08-18 16:27:40 | Re: multi column foreign key for implicitly unique columns |