Re: Refactoring on DROP/ALTER SET SCHEMA/ALTER RENAME TO statement - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Refactoring on DROP/ALTER SET SCHEMA/ALTER RENAME TO statement
Date
Msg-id 28162.1321552825@sss.pgh.pa.us
Whole thread Raw
In response to Re: Refactoring on DROP/ALTER SET SCHEMA/ALTER RENAME TO statement  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Refactoring on DROP/ALTER SET SCHEMA/ALTER RENAME TO statement
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: ISN was: Core Extensions relocation
Next
From: Jeff Davis
Date:
Subject: Re: Are range_before and range_after commutator operators?