Stephan Szabo <sszabo@megazone23.bigpanda.com> writes:
> Tom had suggested storing a more
> understandable form of the foreign key constraint
> to make dumping more reasonable in its own table.
> I'd guess like the src stored for check constraints.
I wasn't actually thinking of storing source, but rather precompiled
expressions (as I remarked awhile ago, I think pg_relcheck's rcsrc
column is dead weight; we could and should generate the value on demand
by reverse-listing rcbin instead). This gets you away from
rename-induced problems since everything is table OIDs, attribute column
numbers, operator and function OIDs, etc.
However, digging those references out of the expression tree is a little
bit painful; you're right that we shouldn't expect applications to do
that for themselves. We could store an additional list of referenced
items. We wouldn't necessarily have to store that explicitly either,
though --- functions to say "is this OID referenced in this stored
expression" or perhaps "give me an array of all function OIDs in this
expression" would get the job done AFAICS.
> One of the problems I see is that if taken to its end,
> would you store function oids here? If so, that might
> make it harder to allow a drop function/create function
> to ever work transparently in the future.
I don't think we should worry about that. What's actually needed IMHO
is an "ALTER FUNCTION" command that allows you to replace the body of
an existing function, and perhaps change its name, but NOT its type
signature (result type and number/types of arguments). Changing the
signature is inherently not a transparent operation because it'd
invalidate stored expressions that use the function. ALTER would let
you make safe changes to a function without changing its OID and thus
without invalidating references-by-OID.
regards, tom lane