Disclaimer: the following is only my view on the matter and is not meant
as representative of the project views, which are reached through
discussion and consensus. IOW, my 2ยข.
Joseph Adams <joeyadams3.14...@gmail.com> writes:
> Perhaps we could have some sort of LET statement that allows the
> client to pass data to the server, then have libpq automatically wrap
> queries with the LET statement (when necessary). Here's what it would
> look like to the PHP scripter:
My first reaction reading this would be to keep the idea but extend the
WITH syntax instead, so you'd have
WITH BINDINGS bob AS (
current_user = 'bob'
)
SELECT answer FROM secrets WHERE user=current_user AND question=$1;
That said, you can already (as of 8.4) do the following:
WITH bob(name) AS (
SELECT 'bob'
)
SELECT answer FROM secrets, bob WHERE user=bob.name AND question=$1;
The syntax WITH bob(current_user) is not possible because of the
standard using current_user as a keyword (IIUC), but you get the idea.
> Granted, it would be silly to pass the value itself to the server over
> and over, so a serious implementation would probably pass a context
> ID, and these variable assignments would live in the backend instead.
I wonder if creating a temporary (I mean per-backend) new catalog where
to store the bindings (or whatever you name them) and then allow another
syntax like the following would help here:
WITH BINDINGS bob ()
SELECT ...
The real problem though is that when using a transaction level pooling
system you want to tie your bindings to a transaction, not to a
session. So I'm not sure if storing the bindings in a local backend
catalog is a must-have feature.
Regards,
--
dim
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
