Backslash as ordinary char vs. not; set via a connection/session variable - Mailing list pgsql-general

From Ken Johanson
Subject Backslash as ordinary char vs. not; set via a connection/session variable
Date
Msg-id 44C8FB3B.9090507@kensystem.com
Whole thread Raw
Responses Re: Backslash as ordinary char vs. not; set via a connection/session variable  (Alvaro Herrera <alvherre@commandprompt.com>)
Re: Backslash as ordinary char vs. not; set via a connection/session  (Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>)
List pgsql-general
Tom and folks,

Will it be possible to set this more standard backslash handling
behavior -- and possibly similar conformance modes... in a way similar
to how mysql allows? They allow one to issue commands on the connection
like:

SET SESSION sql_mode = 'NO_BACKSLASH_ESCAPES,IGNORE_SPACE,ANSI'

The advantage to this is that ISPs, etc can, by default, run the
database with the old/incorrect mode (which is more compatible with the
correspondingly legacy/broken apps.. and for newer apps to issue that
command to make the DB act more standards compliant..

I personally have no need for the old backslash behavior (currently
using databases/queries that don't use it), but sometimes one may have
to coexist in a shared server environment.

(for those who may not know,) the actual overhead of issuing that
command (on the client side at least) before each exec is low, since
connection pools for example usually already need to issue a 'ping'
command (e.g SELECT 1) to test the connection before executing on it. So
if the pool/api allows the user to define connection-setup DML, that
conveniently takes the place of the ping anyway (if the API supports).
And, given that the last user of a pooled connection may have tweaked
the settings, it's prob. best to reset them before each exec.

I seem to have lost the URL that describes the upcoming string
conformance mode.. can't find the 4.1.2.1 section that John Gunther
mentioned.. does anyone have that handy?

Thank you,

ken




pgsql-general by date:

Previous
From: Richard Huxton
Date:
Subject: Re: Can't start PostgreSQL
Next
From: Richard Huxton
Date:
Subject: Re: PostgreSQL theoretical maximums.