Re: Need feedback on new feature (\for) - Mailing list pgsql-general

From Tom Lane
Subject Re: Need feedback on new feature (\for)
Date
Msg-id 12024.1061138456@sss.pgh.pa.us
Whole thread Raw
In response to Need feedback on new feature (\for)  (Martijn van Oosterhout <kleptog@svana.org>)
Responses Re: Need feedback on new feature (\for)  (Martijn van Oosterhout <kleptog@svana.org>)
List pgsql-general
Martijn van Oosterhout <kleptog@svana.org> writes:
> grant select on ":2" to ":1"=20
> \for select usename, relname from pg_catalog.pg_user, pg_catalog.pg_class w=
> here relname not like 'pg_%';

> Thoughts welcome.

Interesting but it seems awfully messy as-is.  How about something like

\for
... control query here ...
\do
... one or more queries here ...
\done

This would eliminate the single-line restriction on the control query
and also allow more than one query in the loop body.  I don't have a
clear idea of what it would take to implement, but I'm visualizing
the \for and \do commands as setting flags that would prevent queries
from actually being sent to the backend; they'd just get stacked up in
a pair of buffers.  Then \done executes the loop and resets the flags.

> 2. If the results being substituted contain quotes, they might not
> substitute cleanly. Do we care?

Yes.  I would argue that the style of substitution you propose is all
wrong.  The substituter should not look inside single- or double-quoted
literals --- writing colon in a literal shouldn't become fraught with peril.
Rather, substitute for :n when it appears outside any quotes, and let
the substituted value include the needed quotes.
Maybe "for" could include some specification of the expected quoting
style, along the lines of
    \for string,string,number
"string" would imply that the corresponding :n symbol is replaced by
a correctly single-quoted literal; perhaps "name" to replace by a
correctly double-quoted literal; "number" to just substitute exactly
what comes back from the query.  (These choices of names could probably
be improved upon, but you get the idea --- sort of a weak form of
declaring datatypes for the parameters.)

> 4. Should it list the commands being executed?

Not by default, but I like the idea of a test mode.

> 5. What should happen upon an error in the generated query?

Abort the loop.

            regards, tom lane

pgsql-general by date:

Previous
From: Karsten Hilbert
Date:
Subject: Re: Need feedback on new feature (\for)
Next
From: Karsten Hilbert
Date:
Subject: Re: Need feedback on new feature (\for)