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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

  From Date Subject
Next Message Vince Vielhaber 2002-06-27 00:29:48 Re: Postgres idea list
Previous Message Rod Taylor 2002-06-27 00:05:16 Re: Postgres idea list