Re: Parser extensions (maybe for 10?)

On 12 April 2016 at 13:28, David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>
wrote:

> ​As recently discovered there is more than one reason why an intelligent
> driver, like the JDBC standard at least requires in a few instances,
> requires knowledge of at least some basic structure​
>
> ​of the statements it sees before sending them off to the server.
>

Indeed.

For one thing, PgJDBC needs to be able to parse the passed SQL text to
extract individual statements and split up multi-statements server-side so
it can bind/parse/execute them separately.

It also has to be able to find placeholders in the query.... and not be
confused by what might be placeholders if not contained within "identifier
quoting", 'literal quoting' or $q$dollar quoting$q$.

I see almost zero utility in teaching the server about client-side
abstractions like {? = call } . Half the *point* of those is that the
*driver* is supposed to understand them and turn them into *DBMS-specific*
syntax. They're escapes.

Furthermore, and particularly in the JDBC example you provide, my first
> reaction is that it would be a massive encapsulation violation to try and
> get PostgreSQL to understand "{? = call funcname(args)}" and similar higher
> level API specifications.
>

+10

Even if it were easy, it'd be an awful idea. It'd also introduce huge
ambiguities as the mess of umpteen different client parameter-specifier
formats, procedure-call escape formats, etc all clashed in a hideous and
confused mess.

This is the client's job. If the client wants to use %(whatever)s, ?, $1,
:paramname, or Σparam☑ as parameter placeholders we shouldn't have to care.
Same with call-escapes etc. So long as we provide a sensible, well defined
way to do what the client driver needs to do to implement what its clients
expect.

Now, I do think we should one day have a proper CALL statement, but that's
for top-level true stored procedures and unrelated to how the client talks
to the client driver.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services