Re: SQL99, CREATE CAST, and initdb

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: SQL99, CREATE CAST, and initdb
Дата
Msg-id Pine.LNX.4.44.0206272301140.1018-100000@localhost.localdomain
обсуждение исходный текст
Ответ на Re: SQL99, CREATE CAST, and initdb  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: SQL99, CREATE CAST, and initdb  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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@gmx.net






В списке pgsql-hackers по дате отправления:

Предыдущее
От: Hannu Krosing
Дата:
Сообщение: Re: Object Oriented Features
Следующее
От: Tim Hart
Дата:
Сообщение: Re: [HACKERS] Support (was: Democracy and organisation)