From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Gurjeet Singh <singh(dot)gurjeet(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: s/UNSPECIFIED/SIMPLE/ in foreign key code? |
Date: | 2012-06-18 12:25:06 |
Message-ID: | 7248.1340022306@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Gurjeet Singh <singh(dot)gurjeet(at)gmail(dot)com> writes:
> The other candidate to look for possible breakage would be pgAdmin. As Amit
> says, there might be code out in the wild that does look at this column, so
> not worth breaking them for this small gain.
Well, I already did it the other way ;-). It's probably not that big a
deal either way, since in practice it's a sure thing that 9.3 will have
many bigger and more-painful-to-deal-with catalog changes than this one.
But the fact that both pg_dump and psql go through pg_get_constraintdef
rather than looking directly at the catalogs, and always have (where
"always" = "since the pg_constraint catalog was invented, in 7.3")
makes me think that other clients probably do likewise. It's rather
painful to get the list of FK column names out of pg_constraint's
array representation in pure SQL.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2012-06-18 12:30:46 | Re: REVIEW: Optimize referential integrity checks (todo item) |
Previous Message | Heikki Linnakangas | 2012-06-18 11:51:45 | Re: [PATCH 06/16] Add support for a generic wal reading facility dubbed XLogReader |