From: | Chris Travers <chris(dot)travers(at)gmail(dot)com> |
---|---|
To: | Postgres General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: feature requests (possibly interested in working on this): functional foreign keys |
Date: | 2013-02-07 16:01:01 |
Message-ID: | CAKt_ZfsMev4CpUeSN6Fbcbg_v+fmEJoXAnoSGC-dpKXMTtYSow@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
(Forgot to CC the list)
On Thu, Feb 7, 2013 at 7:04 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Chris Travers <chris(dot)travers(at)gmail(dot)com> writes:
> > What would be nice to be able to do is to be able to do something like:
> > ALTER TABLE inet_assignment ADD FOREIGN KEY (network(inet_address))
> > REFERENCES cidr_block(block_def);
>
> > 2. Are there any other major showstoppers I haven't thought of?
>
> The information_schema can't represent such a thing, and this is
> unfixable without breaking the SQL standard. I suppose we could omit
> functional FK constraints from the information_schema views, but that's
> not terribly palatable.
>
If this were to be limited to table methods (i.e. functions where
relation.function notation works), would that be sufficiently workable?
>
> Have you considered just storing the network(inet_address) value in a
> separate column (maintained by a BEFORE INSERT/UPDATE trigger) and then
> using a regular FK with that?
>
I have. Honestly I think the UDF + check + trigger is cleaner.
Best Wishes,
Chris Travers
>
> regards, tom lane
>
From | Date | Subject | |
---|---|---|---|
Next Message | Zach Seaman | 2013-02-07 16:01:28 | Re: [NOVICE] Problems with ñ and tildes / CSV import problems in PostgreSQL 9.1 |
Previous Message | Schnabel, Robert D. | 2013-02-07 15:50:55 | Re: 64 bit Win 2008, 32 bit client, ?bit Postgres? |