Re: refactoring comment.c
От | Tom Lane |
---|---|
Тема | Re: refactoring comment.c |
Дата | |
Msg-id | 28438.1282012839@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: refactoring comment.c (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: refactoring comment.c
|
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > On Mon, Aug 16, 2010 at 3:48 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> I think the problem is you're trying to put this into backend/parser >> which is not really the right place for it. > If this isn't parse analysis, then you and I have very different ideas > of what parse analysis is. Maybe so, but the parser is expected to put out a representation that will still be valid when the command is executed some time later. That is exactly why utility statements have the barely-more-than-source parsetree representation they do: because we do not hold locks on the objects from parsing to execution, we could not expect an OID-level representation to remain good. This is a lot different from what we do with DML statements, but there are good reasons for it. I repeat my observation that this code doesn't belong in /parser. The code you're replacing was not in /parser, and that was because it didn't belong there, not because somebody didn't understand the system structure. regards, tom lane
В списке pgsql-hackers по дате отправления: