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
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 |