Refactoring of command.c
От | John Gray |
---|---|
Тема | Refactoring of command.c |
Дата | |
Msg-id | 1014719541.4448.5.camel@adzuki обсуждение исходный текст |
Ответы |
Re: Refactoring of command.c
Re: Refactoring of command.c |
Список | pgsql-hackers |
I thought I should just raise a couple of points -I think I may have been the person Tom Lane was referring with respect to refactoring command.c. I am still happy to go through and do this, though I think that Neil Conway may be active there at present. 1) Division between files. I imagined that the ALTER TABLE would move to alter.c (but maybe this should be altertable.c?), the portal support would live in portal.c and I wasn't sure where LOCK TABLE would go. If we're going to have a command for showing current locks (I seem to remember that from some time back, maybe it would go there too?) 2) Permissions checking and inheritance. Much of the permissions checking and setup on the alter table variants is the same. In my original patch I'd extracted this into a helper routine. Also, all the commands which support inheritance do so using a piece of boilerplate code -I had thought this could become a pair of macros, either side of whatever action was to be performed on the descendant. 3) ALTER TABLE CREATE TOAST TABLE I don't see any need for this in the grammar! AlterTableAddColumn calls it after a catalogue change, it is called (from ProcessUtility tcop/utility.c) for CREATE TABLE, and InitPlan calls it for SELECT INTO. I can't see any useful circumstance in which the command could be issued, which makes it seem a good candidate for removal from the grammar. Any comments on these? John
В списке pgsql-hackers по дате отправления: