Re: Query preparation

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Oliver Jowett <oliver(at)opencloud(dot)com>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, John Lister <john(dot)lister-ps(at)kickstone(dot)com>, pgsql-jdbc(at)postgresql(dot)org
Subject: Re: Query preparation
Date: 2009-04-15 15:11:14
Message-ID: 10718.1239808274@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

Oliver Jowett <oliver(at)opencloud(dot)com> writes:
> Heikki Linnakangas wrote:
>> Does anyone see a problem with caching the result set descriptor
>> (RowDescription)? AFAICS it should never change after a statement is
>> prepared. If not, I'll polish up and submit the patch.

> If you tie it to the existing named statement mechanisms I think that
> works. We invalidate the named statement anyway if the parameter types
> change, and you want to invalidate any cached row description at the
> same time. Schema changes could bite you, but I think they bite named
> statements in other ways anyway. (Not sure how far the server-side
> efforts to do plan invalidation progressed)

It should be safe. The server is set up to throw an error if you try to
re-use a prepared statement whose output tuple descriptor would have
changed due to schema changes. So there's a backstop if the driver's
invalidation logic misses anything.

regards, tom lane

In response to

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message bdbusch 2009-04-15 21:33:54 Re: Deadlock detection
Previous Message Oliver Jowett 2009-04-15 13:11:30 Re: Query preparation