Alvaro Herrera <alvhe...@commandprompt.com> writes:
> It strikes me that if we really want to restructure things to divide
> client interaction from other query-processing routines, we should
> create another file, say src/backend/tcop/queries.c; this would have
> stuff like pg_plan_query, pg_plan_queries, pg_rewrite_query, and the
> other things that the patch was evicting from postgres.c (plus, I
> imagine, a bunch of other stuff that I may be missing). In fact, if we
> go down this route, there would be no point in removing
> pg_parse_and_rewrite; we would just move it to this new module.
Yeah, possibly that would be a good idea.
To my mind, the first thing that has to be resolved before messing
around in this area is whether or not we want the logging/statistics
behavior of these functions to apply when they are used in contexts
other than interactive queries. Personally I would vote no, mainly
because I don't think that behavior is very sensible in nested
execution. If that is the decision, then probably these functions
should stay where they are and as they are, and we just deprecate
outside use of them. I'm not sure whether there's enough left after
deleting the logging/statistics behavior to justify making exported
versions, as opposed to just having the callers call the next-layer-down
functionality directly.
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
