Re: libpq: What can and cannot be bound? How to know?

On Wed, Jun 21, 2023 at 4:20 PM David G. Johnston <
david(dot)g(dot)johnston(at)gmail(dot)com> wrote:

> The planner is the thing that handles binds. [...]
>

Depends what you mean by "handles", since when I asked about "bind peeking"
during planning,
I think the answer was that it was not supported. So I don't see the
different link between planning per-se
and binds, which seem more related to the executor once a plan was chosen,
from my naive perspective.

But of course, I'm reasoning purely on my little abstract understanding of
what that machinery could be...

> Reworking that core design choice doesn't seem like a great use of time.
> Especially when alternatives exist.
>

Are you saying conn.exec("NOTIFY {}, {}", conn.escapeName(channel),
conn.escapeLiteral(payload))
is somehow worse than conn.exec(bind(channel, payload), "SELECT
pg_notify($1, $2)")?
I'm not asking in the abstract, as I'll be wrapping these in typesafe and
SQL-injection-safe wrappers soon.

And since channel is a name, does the string bound to the pg_notify() call
needs to be escaped or not?
I've had "loads of fun" troubleshooting why ::regrole casts failed for
names that need escaping,
so it's not a rethorical question either... Whether a function taking a
name requires the name to be
escaped on the "outside", or will be escaped "inside", is not really
specified, at least that I can see.

> Specifically, the pg_notify function that can be parameterized and handles
> the SQL-injection stuff for you.
>

Sure, for that one example, there's a function equivalent that allows
wrapping.
Is that a native function? Or a SQL or PL/SQL function that just basically
does the escape*()
that I showed above? Note that performance matters much between the two,
but I'm curious.

Still, not all SQL COMMAND taking names and/or literals are similarly
wrapped in functions.
So my point remains. That you think there's low to zero value in it, sure,
I get it. --DD