Re: TODO item: list prepared queries
От | |
---|---|
Тема | Re: TODO item: list prepared queries |
Дата | |
Msg-id | b6d7005f5178590b06ae988bb409f343@ обсуждение исходный текст |
Ответ на | Re: TODO item: list prepared queries (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: TODO item: list prepared queries
|
Список | pgsql-patches |
On December 14, 4:58 pm Tom Lane <tgl@sss.pgh.pa.us> wrote: > "Michael Paesold" <mpaesold@gmx.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
В списке pgsql-patches по дате отправления: