Re: SQL99, CREATE CAST, and initdb

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Tom Lane writes:
>> Thomas appears to want your schema search path to have some effect on
>> which casts you can see --- which I'm not at all sure I agree with,
>> but if that's the requirement then the above doesn't do it either.

> If I understand this right, this would be nearly analogous to determining
> an operator's underlying function by schema path. That smells an awful
> lot like dynamic scoping, a.k.a. a bad idea, and completely inconsistent
> with the rest of the system.

I don't like it either. ISTM that the casting relationship between two
types is a property of those types and should *not* be affected by your
search path. Maybe you referenced one or both types by qualified
schema names, rather than by finding them in your path, but should that
keep you from seeing the cast? Especially since there's no obvious
place in the CAST syntax to attach a schema qualification, if we try
to insist that one might be needed to get at the desired cast function.

An extreme case is binary-equivalence, which as I mentioned maps nicely
into the sort of pg_cast table you suggested. It doesn't map nicely
into anything that involves schema visibility --- there is no cast
function to hide or make visible. Even more to the point, if types A
and B are binary-equivalent, should changing my search path make them
stop being so? Doesn't make sense to me.

> Sure. However, AFAIK, the current development progress has already broken
> the previous expectations slightly by requiring that implicit casting
> paths be explicitly declared.

True. If we wanted to maintain the old behavior exactly then we could
allow this hypothetical GUC variable to also cause old-convention cast
functions to be automatically marked IMPLICIT CAST. (I suppose the
IMPLICIT CAST bit would actually stop being a property of functions at
all, and would become a column of pg_cast.)

regards, tom lane