Fernando Nasser <fnasser@redhat.com> writes:
> (Please note that "[PATCHES] Allow arbitrary levels of
> analyze/rewriting" must be applied before this patch)
Actually, it looks like you accidentally included that patch as part of
this one. Since Bruce already applied that patch, this one will not
apply cleanly.
While this looks good as far as it goes, I don't think it
resolves the problems exposed by Coax's recent complaint:
http://archives.postgresql.org/pgsql-bugs/2002-02/msg00155.php
There are two remaining bogosities:
1. We need to get rid of the static variable CommandInfo that's
manipulated by UpdateCommandInfo; static state is certainly going
to be a bad idea in this context.
2. EndCommand should *not* be issued until we have completed all the
actions of the (rewritten) query. Moving EndCommand into
PerformPortalFetch, as you did here, is exactly the wrong direction.
What we need is for EndCommand to be executed from pg_exec_query_string.
That means that the tag auxiliary info (currently set up by
UpdateCommandInfo) has to be passed out from ProcessQuery to
pg_exec_query_string, which is the only place that can know when to send
the command completion notice back to the client.
As the comments in dest.h and dest.c point out, BeginCommand/EndCommand
are fairly confused in purpose and usage right now. Maybe rather than
patching, we ought to decide what functionality we really need and do a
major reconstruction job.
One rather nasty issue that arises here is that I don't think
pg_exec_query_string has enough knowledge to understand which of the
queries produced by query rewriting corresponds to the "original" query.
This is critical in order to figure out which command's auxiliary info
is the right stuff to pass back to the client. I suspect we will need
to expand QueryRewrite's API to identify the "main" query in the
returned query list.
Seems like we've opened a real can of worms here...
regards, tom lane