Re: [HACKERS] pg_get_prepared?
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
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] pg_get_prepared?
Am Freitag, 15. Juli 2005 14:19 schrieb Greg Sabino Mullane: > > The use case is when you want to prepare a query, but only if it's not > > already prepared on that connection. > > 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. Does not apply to mod_php/apache, you simply do not know if a connection made my pg_pconnect is a new connection or a reused one. That has nothing to do with the application itself. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] pg_get_prepared?
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. Chris ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] pg_get_prepared?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > The use case is when you want to prepare a query, but only if it's not > already prepared on that connection. 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. - -- Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200507151017 https://www.biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iEYEARECAAYFAkLXxcsACgkQvJuQZxSWSsgJOgCg+jKQzGW+Xgh+4rAooS01jxse fa0AnRG5ODx2N0gc8BG3LeYAYUVmICJX =eLkO -END PGP SIGNATURE- ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] pg_get_prepared?
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes: > Would it be useful to have a pg_get_prepared(name) function that returns > true or false depending on whether or not there is a prepared query of > that name? This has been discussed as something needed at the protocol level, not a SQL function. > Perhaps we could have a way of checking the parameter types of it as well? That's called Describe Statement. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] pg_get_prepared?
On 7/15/05, Christopher Kings-Lynne <[EMAIL PROTECTED]> wrote: > > You're mentioning about PHP PostgreSQL API, right? > > No, I'm talking about a PostgreSQL backend function. Sorry, when you give a name like pg_get_prepared() (which is used in PHP PostgreSQL API functions), I thought it's for PHP too. > The use case is when you want to prepare a query, but only if it's not > already prepared on that connection. As Neil Conway explained on IRC - this feature can be useful for connection pools. E.g. avoid re-preparing a stmt. if a previous client using the conn. already prepared it. > Same way that the EXECUTE command checks. If it'll be done from backend, then there's no problem. I wondered the PHP side of it. Anyway, it wasn't a PHP function. Regards. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] pg_get_prepared?
Christopher Kings-Lynne wrote: Would it be useful to have a pg_get_prepared(name) function that returns true or false depending on whether or not there is a prepared query of that name? From the TODO: * Allow pooled connections to list all prepared queries So this has been raised before. -Neil ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] pg_get_prepared?
Volkan YAZICI wrote: Hi, On 7/15/05, Christopher Kings-Lynne <[EMAIL PROTECTED]> wrote: Would it be useful to have a pg_get_prepared(name) function that returns true or false depending on whether or not there is a prepared query of that name? (You're mentioning about PHP PostgreSQL API, right?) I couldn't see any proper usage area for this. Can you give some examples? No, I'm talking about a PostgreSQL backend function. The use case is when you want to prepare a query, but only if it's not already prepared on that connection. Furthermore, I wondered the steps you'll follow to achieve this. How will you check if a prepared stmt exists or not? Same way that the EXECUTE command checks... Chris ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] pg_get_prepared?
Hi, On 7/15/05, Christopher Kings-Lynne <[EMAIL PROTECTED]> wrote: > Would it be useful to have a pg_get_prepared(name) function that returns > true or false depending on whether or not there is a prepared query of > that name? (You're mentioning about PHP PostgreSQL API, right?) I couldn't see any proper usage area for this. Can you give some examples? Furthermore, I wondered the steps you'll follow to achieve this. How will you check if a prepared stmt exists or not? Regards. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[HACKERS] pg_get_prepared?
Hi guys, Would it be useful to have a pg_get_prepared(name) function that returns true or false depending on whether or not there is a prepared query of that name? Perhaps we could have a way of checking the parameter types of it as well? (Also no-one replied to my PQescapeIdentifier suggestion :) ) Chris ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
