Re: Foreign keys for non-default datatypes - Mailing list pgsql-hackers

From Stephan Szabo
Subject Re: Foreign keys for non-default datatypes
Date
Msg-id 20060303090543.T90045@megazone.bigpanda.com
Whole thread Raw
In response to Re: Foreign keys for non-default datatypes  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Foreign keys for non-default datatypes
List pgsql-hackers
On Fri, 3 Mar 2006, Tom Lane wrote:

> Stephan Szabo <sszabo@megazone.bigpanda.com> writes:
> > On Thu, 2 Mar 2006, Tom Lane wrote:
> >> 1. If the index opclass contains an exact operator for the case
> >> "PKtype = FKtype", use that operator.
>
> > Is this rule to read explicitly naming '=' or just the item in that
> > position in the opclass?
>
> The operator occupying the equality position in the opclass.

Okay.

> > I think it's an acceptable idea to fail if we're going to extend the
> > cross-type indexing support, but AFAICS we have to at the very least allow
> > all of the "standard" numeric types in all combinations to work to meet
> > the spec, and I don't think the above rules and current opclasses will
> > give that to us (and I don't honestly understand some of the bits of this
> > to know if there's a problem with extending the opclasses to allow that).
>
> The cases that are likely to be problematic are things like a FLOAT8
> column referencing a NUMERIC primary key.  However, that sort of
> mishmash is fraught with all kinds of risks anyway (think roundoff
> error) so the fact that the spec nominally allows it doesn't tell me
> that we ought to encourage it.

There's a bit of difference between not encouraging it and disallowing it
entirely, but I'm willing to buy that argument.  I do think that numeric
reference int needs to be allowed though, and I thought that's also
currently not there (although int reference numeric should work I think).



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: PG Extensions: Must be statically linked?
Next
From: Tom Lane
Date:
Subject: Re: ipcclean in 8.1 broken?