Re: TODO item: list prepared queries

On December 14, 4:58 pm Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Michael Paesold" <mpaesold(at)gmx(dot)at> writes:
> > Well, I think for the driver or application, to recognize queries as
> > their own, it seems much easier if the query is given exaclty as it
> > was sent.

> Depends on what the intended use of the view is, I suppose --- but I
> should think that drivers would tend to just look at the statement name
> to decide if it's something they sent, rather than comparing the text
> of the body.

Well, one could argue that relying on the identifier might be dangerous.
Someone else could prepare a query with the identifier of another
application and thus this application might execute something different
than what it actually wants to, but then we're in the area of how to manage
users and pooled connections.

Anyway as you say it depends on what you want to use the view for. For an
automatised usage the deparsed form is of no value, for your eye however it
might be nicer.

Another problem I just found out: you can drop a table a prepared query is
referring to. Can the reverse-compiling function cope with that situation?
Well, the cleanest solution might be to prevent this in the first place...

Why not just display both versions?

> Also, while I have not looked at the patch to see where it's getting
> the "original text" from, I'll bet lunch that it's wrong.

It uses the query string that was already in the prepared queries hash
table. This one uses debug_query_string. I'm a poor student and can't
afford paying you a lunch, but I'd offer you a coke if you tell me why this
is wrong ;-)

Joachim