Robert Haas <robertmh...@gmail.com> writes:
> On Tue, Aug 17, 2010 at 2:24 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> 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.
Yeah, and that's exactly what happens with utility statements that (for
example) get into the plan cache.
> 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.
The reason to not do that is that you'd have to hold more locks,
and do more management of those locks, in order to protect the
more-thoroughly-analyzed statements from parsing to execution. In the
case of utility statements, particularly ones that affect a lot of
objects, I think that would be a seriously bad idea. In fact it would
fly in the face of lessons we learned the hard way. The whole of
parser/parse_utilcmd.c is code that we used to execute "at parse time",
and had to rearrange to postpone to execution time, in order to avoid
nasty bugs. It's still in backend/parser because it fits well there
and uses a lot of parser infrastructure that's shared with parse-time
analysis of DML statements. But neither of those statements hold for
the ObjectAddress resolution code.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
