Thread: PREPARE, FK's and VIEWs

PREPARE, FK's and VIEWs

From
"Christopher Kings-Lynne"
Date:
Hi,

Now that we have prepared statements, should the foreign key code be changed
to use them?  I think it's highly likely that they will be reused in a
connection.  Might be an idea.

Also, what if the person wants to prepare a view?  Should they have to
PREPARE <view select> or should we automatically prepare them the first time
they're used in a connection?  Or should we offer a PREPARE VIEW <viewname>
option?

I personally think the second option would be neat.

Chris



Re: PREPARE, FK's and VIEWs

From
Karel Zak
Date:
On Wed, Aug 28, 2002 at 02:53:46PM +0800, Christopher Kings-Lynne wrote:
> 
> Now that we have prepared statements, should the foreign key code be changed
> to use them?  I think it's highly likely that they will be reused in a
> connection.  Might be an idea.
No FK, but more common is integrate query plan cache to SPI (saveplan).I don't how it's in the current implementation.
   Karel

-- Karel Zak  <zakkr@zf.jcu.cz>http://home.zf.jcu.cz/~zakkr/C, PostgreSQL, PHP, WWW, http://docs.linux.cz,
http://mape.jcu.cz


Re: PREPARE, FK's and VIEWs

From
Tom Lane
Date:
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
> Now that we have prepared statements, should the foreign key code be changed
> to use them?  I think it's highly likely that they will be reused in a
> connection.  Might be an idea.

Waste of time; the FK code already does this for itself.

> Also, what if the person wants to prepare a view?

What does that mean?  A view isn't preparable in isolation from the
query that's going to use it.
        regards, tom lane


Re: PREPARE, FK's and VIEWs

From
Stephan Szabo
Date:
On Wed, 28 Aug 2002, Christopher Kings-Lynne wrote:

> Now that we have prepared statements, should the foreign key code be changed
> to use them?  I think it's highly likely that they will be reused in a
> connection.  Might be an idea.

It might be worth doing eventually just to standardize, but it should
save query plans internally already.