Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> But I think I see what Tom objection to it is: if we "export" this
> capability to libpq applications, then we set it in stone to a certain
> extent: exactly how things are split would become part of the API, so to
> speak. Upgrading to a newer libpq could break application code that
> worked with the previous release's by splitting things differently.
That's not exactly what the problem is: an upgrade could only break
*existing* application code if we had made a non-backward-compatible
change in SQL lexical rules, which hopefully we'd never do.
Rather, the problem is that the server might know about some newer
lexical feature, and so might the application, but if libpq is behind
the times then it's broken. You can see an instance of this right now
over in the pgsql-jdbc list, where they're arguing about fixing the
JDBC driver to understand dollar quoting. Application authors not
unreasonably think it should have heard of that by now.
The JDBC example is sort of an argument in favor of Karl's idea,
in that if client-side code is going to know this anyway then it would
be better if it were at least localized in one place. But of course
JDBC is never going to depend on libpq (wrong language) so moving this
code into libpq isn't actually going to help them.
A larger point is that I don't believe this is actually going to help
anybody, because of mismatch of requirements not only implementation
language. JDBC couldn't use a libpq lexer implementation even without
the language issue, because the context in which they're arguing about
this is finding and replacing JDBC-spec escape sequences, which libpq is
not going to know about. I imagine PHP has got the same problem only
different. Conversely, psql's lexer has a lot of psql-specific design
decisions, such as the need to handle backslash commands and include
files, that I don't think would belong in a libpq implementation.
regards, tom lane
