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

Re: proof concept: do statement parametrization

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Florian Pflug <fgp(at)phlo(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proof concept: do statement parametrization
Date: 2010-07-04 16:22:32
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> This whole proposal strikes me as premature. What we need is some 
> experience from the field in using DO before we can sensibly decide how 
> it should be extended. And we won't get that until 9.0 has been released 
> and used for a while.


What strikes me about this proposal is that there isn't any way to pass
parameter strings without worrying about how to escape them; which means
that the actual functionality gain over 9.0 is at best rather limited.

Now you could get to that if we had support for utility statements
accepting parameter symbols, ie you could execute
	DO ... USING $1, $2
with out-of-line parameter values passed using the PQexecParams protocol.
So maybe that's an orthogonal feature that should be done as a separate
patch, but without it I'm not sure there's really much point.

IIRC one of the stumbling blocks for parameters in utility statements
is that usually there's no good context for inferring their data types.
If we were to extend DO in the particular way Pavel suggests, then
there would be context for that case, but I'm not sure what we do about
the general case.  We'd want to think about that before installing a
special-purpose rule that only works for DO.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Andres FreundDate: 2010-07-04 16:25:18
Subject: Re: proof concept: do statement parametrization
Previous:From: Pavel StehuleDate: 2010-07-04 15:50:11
Subject: Re: proof concept: do statement parametrization

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