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