PREPARE code notes

Karel Zak <zakkr@zf.jcu.cz> writes:

1/ ExecuteQuery() (line 110). Why is needful use copyObject()? The
PostgreSQL executor modify query planns?

Yes, and yes. Unfortunately.

2/ Lines 236 -- 245. Why do you "check for pre-existing entry of
same name" if you create hash table? I think better is use "else"
for this block of code and check it only if hash table already
exist.

The code reads more cleanly as-is; changing it as you suggest would
create an unnecessary interdependency between two logically distinct
concerns.

3/ Last is cosmetic: see line 404, what happen if memory context
is not valid? :-) (maybe use some elog() call)

Or just get rid of the MemoryContextIsValid test --- it shouldn't
ever not be valid. Not very important though.

regards, tom lane

On Mon, Sep 09, 2002 at 11:51:08AM -0400, Tom Lane wrote:

Karel Zak <zakkr@zf.jcu.cz> writes:

1/ ExecuteQuery() (line 110). Why is needful use copyObject()? The
PostgreSQL executor modify query planns?

Yes, and yes. Unfortunately.

Hmm, it's bad. Is there any way to "fix" executor? Maybe in far
future we will save to cache all planns and copyObject() is not
performance winning.

2/ Lines 236 -- 245. Why do you "check for pre-existing entry of
same name" if you create hash table? I think better is use "else"
for this block of code and check it only if hash table already
exist.

The code reads more cleanly as-is; changing it as you suggest would
create an unnecessary interdependency between two logically distinct
concerns.

I don't believe :-)

Karel

--
Karel Zak <zakkr@zf.jcu.cz>
http://home.zf.jcu.cz/~zakkr/

C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz

Karel Zak <zakkr@zf.jcu.cz> writes:

On Mon, Sep 09, 2002 at 11:51:08AM -0400, Tom Lane wrote:

PostgreSQL executor modify query planns?

Yes, and yes. Unfortunately.

Hmm, it's bad. Is there any way to "fix" executor?

It should be fixed IMHO ... but it'll be a major restructuring and
it's difficult to justify spending the time ...

regards, tom lane