From: | Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com> |
---|---|
To: | Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Set search_path + server-prepared statements = cached plan must not change result type |
Date: | 2016-01-20 08:14:47 |
Message-ID: | CAB=Je-GQOW7kU9Hn3AqP1vhaZg_wE9Lz6F4jSp-7cm9_M6DyVA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
There's a not so well known issue of "set search_path" and
"server-prepared statement" usage.
In short, it does not always work. See more details in [1].
There issue has reproduced once again recently (see [2], that explains
that search_path is modified for a multi-tenant setup).
Even though I wish that kind of details were handled at the backend
level (see Tom's example in [1] when "create table" should invalidate
the statement), we need to do something about that with existing PG
versions. Otherwise it is another "never modify search_path" or "never
use server-prepared" catch-22.
Here's my question: why change in search_path does NOT generate
ParameterStatus message from the backend?
I thought I could capture ParameterStatus events, and use
per-search_path cache at the JDBC level. However that does not seem to
work.
Here's what I get with 9.5rc1:
simple execute, maxRows=0, fetchSize=0, flags=17
FE=> Parse(stmt=null,query="SET search_path TO "$user",public,schema2",oids={})
FE=> Bind(stmt=null,portal=null)
FE=> Describe(portal=null)
FE=> Execute(portal=null,limit=0)
FE=> Sync
<=BE ParseComplete [null]
<=BE BindComplete [unnamed]
<=BE NoData
<=BE CommandStatus(SET)
<=BE ReadyForQuery(I)
Am I missing something?
[1]: http://www.postgresql.org/message-id/22921.1358876659@sss.pgh.pa.us
[2]: https://github.com/pgjdbc/pgjdbc/issues/496
Vladimir Sitnikov
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2016-01-20 08:19:50 | Re: Inconsistent error handling in START_REPLICATION command |
Previous Message | Shulgin, Oleksandr | 2016-01-20 07:50:43 | Re: Stream consistent snapshot via a logical decoding plugin as a series of INSERTs |