Re: Foreign keys for non-default datatypes, redux

Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> writes:
> I assume you're speaking of the version where we just change the
> constraints to use statements with the OPERATOR() syntax and potential
> casts rather than the discussion at the end about changing the pk checks
> to avoid planning entirely?

Yeah, we might get around to doing that someday but I'm not excited
about it right now. (I'm mainly doing this because it fits in with the
operator-family work I've been doing --- that also got rid of some
unsupportable assumptions about operators being named "=" ...)

> I'd say we probably want to keep the tgargs info for at least a version or
> two after changing the implementation. Getting rid of using the args info
> sounds like a good idea.

We whack the catalogs around in incompatible ways in every release. I'm
willing to keep filling tgargs if someone can point to a real use-case,
but not just because there might be code out there somewhere using it.

> One side question is what should we do about the
> places in the current system where it checks for the key sets being empty?

I don't see that this affects that either way. I can't quite imagine
what the semantics would be, though --- there's no such thing as a
unique constraint with no columns, so how can there be an RI constraint
with none?

regards, tom lane