Re: Refactoring on DROP/ALTER SET SCHEMA/ALTER RENAME TO statement

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Refactoring on DROP/ALTER SET SCHEMA/ALTER RENAME TO statement
Дата
Msg-id 28162.1321552825@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Refactoring on DROP/ALTER SET SCHEMA/ALTER RENAME TO statement  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Refactoring on DROP/ALTER SET SCHEMA/ALTER RENAME TO statement
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> It also eliminates the NOTICE when removing a built-in
> function, which I think is OK because you don't actually get that far:

There are paths that can reach that notice --- I think what you have to
do is create a new function that references a built-in one.  But why
we bother to warn for that isn't clear to me.

> - For some reason, we have code that causes procedural language names
> to be downcased before use.

I think this is a hangover from the fact that CREATE FUNCTION's LANGUAGE
clause used to insist on the language name being a string literal, and
of course the lexer didn't case-fold it then.  That's been deprecated
for long enough that we probably don't need to have the extra case-fold
step anymore.
        regards, tom lane


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: ISN was: Core Extensions relocation
Следующее
От: Jeff Davis
Дата:
Сообщение: Re: Are range_before and range_after commutator operators?