* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Matthew <matthew@zeut.net> writes:
> > Is it worth having a GUC variable that enables / disable this?
>
> That's a given, I think. We're certainly not going to make smash-to-
> lower-case the only available behavior.
A GUC variable for this would be quite nice.. I had some difficulty
porting a MySQL application to PostgreSQL because it used PHP and PEAR,
which allows you to create a database 'object' and then reference things
inside it which are actually column names, ie:
$db = ...;
$myvar = $db->Column1;
That kind of stuff, where it did quoting on the actual DB request and
made moving it from MySQL to PostgreSQL a big pain, even though the rest
of the application was pretty good SQL. What made it that much more
difficult was that there were places in the application which used
direct SQL statements and the identifiers in those weren't quoted. :/
Or maybe that was the original problem... Anyhow, I *think* PEAR has
been changed now to not quote but I'm not 100% sure; I just fixed the
application, noted the issue, and moved on.
> One issue we might want to reflect on is how easy it should be to change
> the variable's setting. Our bad experience with autocommit leaves me a
> bit wary of fundamental behavioral changes that can be flicked on and
> off at whim. However, we have pretty much the same problem staring us
> in the face for backslash-in-literal-strings behavior, so maybe we can
> find an answer we like for both issues at the same time.
That'd be very nice...
Thanks,
Stephen