Re: refactoring comment.c

On Tue, Aug 17, 2010 at 2:24 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Tue, Aug 17, 2010 at 11:30 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Rereading this, I see I didn't make my point very clearly.  The reason
>>> this code doesn't belong in parser/ is that there's no prospect the
>>> parser itself would ever use it.  ObjectAddress is an execution-time
>>> creature because we don't want utility statement representations to be
>>> resolved to OID-level detail before they execute.
>
>> Well, that is a good reason for doing it your way, but I'm slightly
>> fuzzy on why we need a crisp separation between parse-time and
>> execution-time.
>
> I don't insist that the separation has to be crisp.  I'm merely saying
> that putting a large chunk of useful-only-at-execution-time code into
> backend/parser is the Wrong Thing.

OK, but there should be a reason for that. For example, if there are
circumstances when we parse a statement, and then time passes, and
then we execute it later, that's a good argument for what you're
saying here. But otherwise, the fact that these bits of barely-parsed
stuff get passed all over the backend seems like an inconvenient wart.
I was actually thinking of proposing that we make more things happen
during the parsing process and postpone less to the execution phase,
and I need to make sure that I understand why you don't want to do
that.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company