Rethinking parameterized SQL queries John Cowan (27 Feb 2021 01:18 UTC)
Re: Rethinking parameterized SQL queries Lassi Kortela (27 Feb 2021 09:13 UTC)
Re: Rethinking parameterized SQL queries Lassi Kortela (27 Feb 2021 09:17 UTC)
Re: Rethinking parameterized SQL queries Lassi Kortela (27 Feb 2021 09:30 UTC)
Re: Rethinking parameterized SQL queries John Cowan (27 Feb 2021 20:08 UTC)
Re: Rethinking parameterized SQL queries Lassi Kortela (27 Feb 2021 20:36 UTC)
Re: Rethinking parameterized SQL queries John Cowan (27 Feb 2021 22:14 UTC)
Re: Rethinking parameterized SQL queries Peter Bex (28 Feb 2021 10:21 UTC)
Re: Rethinking parameterized SQL queries John Cowan (01 Mar 2021 03:29 UTC)
Re: Rethinking parameterized SQL queries Florian Weimer (27 Feb 2021 12:32 UTC)
Re: Rethinking parameterized SQL queries Lassi Kortela (27 Feb 2021 12:39 UTC)

Re: Rethinking parameterized SQL queries Peter Bex 28 Feb 2021 10:21 UTC
On Sat, Feb 27, 2021 at 05:14:05PM -0500, John Cowan wrote:
> That seems like a mere inversion of my OP, except that it assumes good
> stuff on the inside, bad stuff on the outside
>
> On Sat, Feb 27, 2021 at 3:36 PM Lassi Kortela <xxxxxx@lassi.io> wrote:
>
>
> > Free for now. ~ is used for complement or negation in several languages.
> >
>
> Not a problem.  It would certainly not be a heavily used feature, and if
> you do want to use it, you just write it as ~~, the same as you write %% in
> printf strings.

That's a little awkward, because in Postgres ~ is used for regular
expression operators:

https://www.postgresql.org/docs/current/functions-matching.html#FUNCTIONS-POSIX-REGEXP

It also says "The operator ~~ is equivalent to LIKE, and ~~* corresponds
to ILIKE".  So in this proposal, that operator would be written as ~~~~*.

I would probably just go for the question mark, that seems to be the most
commonly used character in other languages.  Personally I'd be happier if
the underlying representation could be used by the programmer.  This
means the driver doesn't need to do anything, it can just pass the string
as-is to the underlying protocol.  It is much less error-prone and safety
is basically guaranteed since you're just relying on the protocol itself.

But then that also means it's not cross-database portable...

Cheers,
Peter