Skip site navigation (1) Skip section navigation (2)

Re: [JDBC] Support for JDBC setQueryTimeout, et al.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>, Radosław Smogura <rsmogura(at)softperience(dot)eu>, Magnus Hagander <magnus(at)hagander(dot)net>, David Fetter <david(at)fetter(dot)org>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>, PostgreSQL JDBC List <pgsql-jdbc(at)postgresql(dot)org>, robertmhaas(at)gmail(dot)com
Subject: Re: [JDBC] Support for JDBC setQueryTimeout, et al.
Date: 2010-10-15 20:22:51
Message-ID: 11068.1287174171@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-jdbc
Stephen Frost <sfrost(at)snowman(dot)net> writes:
>> The whole problem with search_path and role is very frustrating.  We've
>> taken to just hacking things to be dynamic SQL whenever it's
>> role-specific, but that's a really poor solution.  I wonder if it would
>> be possible to have the function and prepare'd plan caches be key'd off
>> of the search_path and role too..?  So if you change one of those you
>> end up having to re-plan it, but then that's also cached, etc..

FWIW, I can see the point of making cached plan lookup be
search-path-specific.  But why does the active role need to factor
into it?

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Dimitri FontaineDate: 2010-10-15 20:45:18
Subject: Trailing Whitespace Tips (was: Re: starting to review the Extend NOT NULL representation to pg_constraint patch)
Previous:From: Stephen FrostDate: 2010-10-15 20:14:40
Subject: Re: [JDBC] Support for JDBC setQueryTimeout, et al.

pgsql-jdbc by date

Next:From: Stephen FrostDate: 2010-10-15 20:58:15
Subject: Re: [JDBC] Support for JDBC setQueryTimeout, et al.
Previous:From: Stephen FrostDate: 2010-10-15 20:14:40
Subject: Re: [JDBC] Support for JDBC setQueryTimeout, et al.

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group