Re: SQL99, CREATE CAST, and initdb - Mailing list pgsql-hackers

From Tom Lane
Subject Re: SQL99, CREATE CAST, and initdb
Date
Msg-id 17087.1025136634@sss.pgh.pa.us
Whole thread Raw
In response to Re: SQL99, CREATE CAST, and initdb  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: SQL99, CREATE CAST, and initdb  (Hannu Krosing <hannu@tm.ee>)
Re: SQL99, CREATE CAST, and initdb  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> Perhaps it wouldn't be such a terrible idea after all to store the casting
> paths separately, such as in a system table pg_cast (from, to, func,
> implicit).  This would implement the SQL99 spec fairly exactly.

Well, maybe.  One question is how that would fit in with schemas.
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 we just want to get out from under the coupling of function name to
cast status, the above would do it ... and also break existing
applications that aren't expecting to have to do something special to
make a function of the right name become a cast function.  Perhaps there
could be a GUC variable to allow created functions matching the old
naming convention to be automatically made into casts?  We could default
it to 'true' for a release or two and then default to 'false'.

BTW, the above would also provide a place to encode binary compatibility
associations in the DB, rather than hard-wired, which would be a Good
Thing.  You could say that func == 0 means that no actual function call
is needed to transform type 'from' to 'to'.
        regards, tom lane




pgsql-hackers by date:

Previous
From: Rod Taylor
Date:
Subject: Re: Postgres idea list
Next
From: Vince Vielhaber
Date:
Subject: Re: Postgres idea list