Re: PQexecParams, placeholders and variable lists of params

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: tomas(at)tuxteam(dot)de, Дмитрий Иванов <firstdismay(at)gmail(dot)com>, pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: PQexecParams, placeholders and variable lists of params
Date: 2021-11-23 15:43:03
Message-ID: 4176869.1637682183@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> On Tue, Nov 23, 2021 at 7:21 AM <tomas(at)tuxteam(dot)de> wrote:
>> Makes sense. Problem is, that, again, the application would be
>> responsible of making sure the individual values don't contain nasty
>> stuff (for example, if they are strings) before consolidating them to
>> one PostgreSQL array literal.

> So long as you actually pass the literal value via a parameter the worst
> problem you can have is a syntax error in converting the literal into
> whatever type is being cast to.

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.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message tomas 2021-11-23 16:17:13 Re: PQexecParams, placeholders and variable lists of params
Previous Message David G. Johnston 2021-11-23 15:35:04 Re: PQexecParams, placeholders and variable lists of params