On Tue, Aug 17, 2010 at 2:24 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Tue, Aug 17, 2010 at 11:30 AM, Tom Lane <t...@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 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
