Re: pg_get_prepared?

From: Kris Jurka <books(at)ejurka(dot)com>
To: Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>
Cc: Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_get_prepared?
Date: 2005-07-16 15:20:22
Message-ID: Pine.BSO.4.56.0507161015540.1675@leary.csoft.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, 16 Jul 2005, Christopher Kings-Lynne wrote:

> > This has been covered before, but to reiterate: why would you need this?
> > Any application worth its salt should be tracking which statements it
> > has already prepared (after all, they cannot span connections). Seems
> > a waste of resources to make a separate call to the database for
> > information you should already know.
>
> Erm, websites...use persistent connections...you have no idea if you're
> dealing with a new connection or a reused one, and if the statement is
> prepared or not.
>

I think the point is that this is the driver's problem, not the
applications. If you are using SQL level PREPARE/EXECUTE in your code
that's your problem, but if you are using an api like:

$stmt = $conn->prepare("SELECT * FROM tab WHERE x = ?");
$result = $stmt->execute(71);

Then the driver itself should know if the above query has been prepared
previously and further what type it has been prepared for so that it can
cast the 71 or prepare a new statement.

Kris Jurka

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kris Jurka 2005-07-16 15:22:10 Re: [HACKERS] 4 pgcrypto regressions failures - 1 unsolved
Previous Message Tom Lane 2005-07-16 14:54:57 Re: [HACKERS] 4 pgcrypto regressions failures - 1 unsolved