On Sun, Feb 27, 2005 at 06:25:18PM -0700, Ken Johanson wrote:
I feel somewhat confident (very actually) that a config option that
disabled the backslash behavior globally(*) would be acceptable, BUT
leave the current backslash behavior turned on by default so that
current users are not impacted at all. Only a conscientious decision by
the db admin to turn it on could cause problems, but _only_ if he/she
didn't warn all his/her users beforehand of the impending change and its
consequences (rtm).
It's not just a question of warning the users, all interfaces to the
database will instantly break. For example: JDBC, Perl DBI, PHP PEAR
etc. They will continue to send queries with the backslashes embedded.
These interfaces would need to be modified to handle both situations
and detect which situation they're dealing with.
All interfaces will NOT break IF the legacy db behavior stays its
default. This means NONE of the current users would be hurt until they
start experimenting with the new option. Yes, the built in prepared
stmt components of those interfaces will still add the backslash by
default and break queries for legacy drivers, but this is not an issue
for the straight-through query/update exec(s) calls, and prepared stmt
users can hack the Prepared stmts behavior until the same option is
officially supported in the driver also (probably by auto-detecting
what the DB expects its backslashes to look like).
I can say, that I for one would enable the no-backslash config option
out of the box -globally -so that we can start using pg now without any
more upper managerial concerns/excuses about language/interface
compliance..I can also say that (what we already know) the longer we
wait to provide the 'right' option, the *more* legacy apps (and
interfaces) will be built around it and consequently suffer when the
need for change eventually comes (almost wholly caused by interop
concerns). And market gain is being hurt now by this incompatibility
with commercial offerings; that's an unfortunate fact.
Even if PostgreSQL implements this now, you will have to wait for new
versions of any client libraries before it's usable. See the autocommit
disaster for an example why people are not rushing into this...
I fully agree. I can see waiting at LEAST 1-3 months before the db
itself has changes committed for alpha testing, but that SURE BEATS
procrastination --which means years worth of more apps and interfaces
being built around the 'backslash' (again, not everyone uses prepared
statement - its not required and not suitable for all situations).
Conversely, the very day the server has an alpha build supporting the
no-backslash mode is the very _first_ day that the jdbc/perl driver
developers can start testing against the changes. Until then all
parties are just sitting still.