[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postgresql-general
Subject:    Re: PQexecParams, placeholders and variable lists of params
From:       tomas () tuxteam ! de
Date:       2021-11-23 16:21:32
Message-ID: YZ0VDBMCPNhNcdot () tuxteam ! de
[Download RAW message or body]


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 specifies how many parameters following are part of \
> the array. The value should point to a structure, that contains pointers to 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 before passing 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 and copying 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's a PITA).

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

Cheers
 - t


["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]