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.14159@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
