On Tue, Aug 17, 2010 at 2:24 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Tue, Aug 17, 2010 at 11:30 AM, Tom Lane <tgl@sss.pgh.pa.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
morethings 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