Re: Possible to run the server with ANSI/ISO string escapeing

From: Martijn van Oosterhout <kleptog(at)svana(dot)org>
To: Ken Johanson <pg-user(at)kensystem(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-general(at)postgresql(dot)org
Subject: Re: Possible to run the server with ANSI/ISO string escapeing
Date: 2005-02-28 09:16:50
Message-ID: 20050228091645.GA27668@svana.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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.

The thing is all these interfaces handle the quoting transparently for
you, so the code is portable already. What you're complaining about is
that you have your own query marshalling and it is not portable.

Incidently, if you disable the backslash quoting, how does one enter
raw binary data including NUL (\0) characters?

The only viable solution I can think of is that it is set at
*connection* time (maybe extra parameters), and unchangable for the
rest of the session. This means that unmodified client interfaces won't
see a difference.

> 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...

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Peter Eisentraut 2005-02-28 10:06:38 Re: row numbering
Previous Message Sebastien FLAESCH 2005-02-28 08:13:22 Suggestion for parameterized queries