On Thu, Nov 17, 2011 at 11:21 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Tue, Nov 15, 2011 at 4:43 AM, Kohei KaiGai <kai...@kaigai.gr.jp> wrote: >> Part-1) DROP statement refactoring >> It is a remaining portion of what I submitted in the last commit fest. >> It allows object types that didn't used DropStmt in gram.y to go >> through RemoveObjects(), instead of individual RemoveXXXX(). > > Review of just this part: > > - I think we can remove the special case for foreign data wrappers > because (1) the only case in which there's any behavioral difference > at all is if a superuser creates a foreign data wrapper (or the > ownership of one is reassigned to him) and he is then made not a > superuser; non-superusers can't create foreign data wrappers, and > existing foreign data wrappers can't be given to non-superusers; > moreover, (2) removing the special case causes the behavior to match > the documentation, which it currently doesn't (but only in the > aforementioned, extremely minor way). > > - On the other hand, this patch blithely nukes the prohibition on > using DROP FUNCTION to remove an aggregate. I'm not sure that's a > good idea. It also eliminates the NOTICE when removing a built-in > function, which I think is OK because you don't actually get that far: > > rhaas=# drop function int4pl(integer, integer); > ERROR: cannot drop function int4pl(integer,integer) because it is > required by the database system > > - For some reason, we have code that causes procedural language names > to be downcased before use. Given that unquoted identifiers are > downcased anyway, this seems a bit redundant. I'm inclined to think > we don't need to preserve that behavior for DROP, especially because > other parts of the code - such as COMMENT - don't know about it > anyway. But rather than just changing it for DROP, I think we should > go through and rip out case_translate_language_name() across the > board, probably as a a separate commit.
I've committed part 1 of this patch series after correcting the above items. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
