Re: PQexecParams, placeholders and variable lists of params

On Tue, Nov 23, 2021 at 05:14:44PM +0100, Daniel Frey wrote:
> > On 23. Nov 2021, at 16:43, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >
> > PG's array quoting rules are odd enough that I can sympathize with not
> > wanting to deal with them.  (Although, if you only have to build an
> > array and not parse one, taking the always-quote-even-if-not-necessary
> > approach makes it easier.)
> >
> > I don't see many other alternatives though.  *Somehow* you have to
> > separate one value from the next.  If you don't want to pass 'em as
> > distinct parameters, then you have to obey some kind of composite-value
> > syntax.
>
> Would it be possible to extend PQexecParams() et.al. like this:
>
> You currently have paramValues[], paramLengths[], and paramFormats[] (plus other parameters that I'll ignore here).
>
> The format may currently be 0 or 1 (TEXT or BINARY). What if we allow 2 for ARRAY? The corresponding  length then
specifieshow many parameters following are part of the array. The value should point to a structure, that contains
pointersto the values, lengths, and formats of the elements. This also allows nested arrays. 

That sounds attractive; I think for my particular case it'd be
overengineering, though...

> If the client library knows that the server is too old to understand it, it may temporarily assemble a string for
those(correctly escaped) values and replace the entries in the original values/lengths/formats arrays temporarily
beforepassing it to the old PQexecParams() implementation. 
>
> If the server is new enough the protocol itself can be extended to send the array more efficiently instead of quoting
andcopying data around. 
>
> This would also hide the quoting rules for arrays nicely, as it doesn't require additional methods for escaping.
(Currently,escaping for arrays is different from other escaping methods, it needs to be done manually and, frankly,
it'sa PITA). 

...but in the general case it sounds useful, yes :)

Cheers
 - t