Re: SQL99, CREATE CAST, and initdb

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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 22:48:20
Message-ID: Pine.LNX.4.44.0206272301140.1018-100000@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

> 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'.

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

--
Peter Eisentraut peter_e(at)gmx(dot)net

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuo Ishii 2002-06-28 01:46:54 Re: Object Oriented Features
Previous Message Christopher Clark 2002-06-27 22:44:54 Re: Object Oriented Features