Re: SQL99, CREATE CAST, and initdb

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: SQL99, CREATE CAST, and initdb
Дата
Msg-id 17087.1025136634@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: SQL99, CREATE CAST, and initdb  (Peter Eisentraut <peter_e@gmx.net>)
Ответы Re: SQL99, CREATE CAST, and initdb  (Hannu Krosing <hannu@tm.ee>)
Re: SQL99, CREATE CAST, and initdb  (Peter Eisentraut <peter_e@gmx.net>)
Список 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 по дате отправления:

Предыдущее
От: Rod Taylor
Дата:
Сообщение: Re: Postgres idea list
Следующее
От: Vince Vielhaber
Дата:
Сообщение: Re: Postgres idea list