PFC <lists@peufeu.com> writes:
> Here is the result of my little experiment, for your viewing pleasure,
I'm having a problem with the terminology here, since AFAICT what your
patch does is exactly not a global "prepare" --- there is no permanently
stored cached plan. That's a good thing probably, but it seems like
the feature needs to be described differently.
I'm also pretty dubious about storing raw text in that catalog. In the
first place, while I've not looked at your patch, I expect you are
pulling the raw text from debug_query_string. That won't work in cases
where multiple SQL commands were submitted in one query string. In the
second place, raw-text SQL commands will be subject to a whole lot of
ambiguity at parse time. If for instance another session tries to use
the command with a different search_path or standard_conforming_string
setting, it'll get different results. While I can think of use-cases
for that sort of behavior, it seems like mostly a bad idea.
I'm thinking that a more appropriate representation would use stored
parse trees, the same as we do in pg_rewrite, and with the same
dependency information so that a stored statement couldn't outlive the
objects it depends on.
Another area that could do with more thought is the hard-wired
association between statement ownership and accessibility. That's
likely to be pretty inconvenient in a lot of cases, particularly
systems that use role membership heavily.
I also wonder whether statements should belong to schemas...
regards, tom lane