On Tue, Nov 23, 2021 at 05:14:44PM +0100, Daniel Frey wrote: > > On 23. Nov 2021, at 16:43, Tom Lane <t...@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
Description: PGP signature
