Skip site navigation (1) Skip section navigation (2)

Re: SQL99, CREATE CAST, and initdb

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Thomas Lockhart <lockhart(at)fourpalms(dot)org>,PostgreSQL Hackers List <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: SQL99, CREATE CAST, and initdb
Date: 2002-06-27 00:10:34
Message-ID: 17087.1025136634@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Peter Eisentraut <peter_e(at)gmx(dot)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



In response to

Responses

pgsql-hackers by date

Next:From: Vince VielhaberDate: 2002-06-27 00:29:48
Subject: Re: Postgres idea list
Previous:From: Rod TaylorDate: 2002-06-27 00:05:16
Subject: Re: Postgres idea list

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group