* Tom Lane (tgl@xxxxxxxxxxxxx) wrote: > Matthew <matthew@xxxxxxxx> 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
Attachment:
signature.asc
Description: Digital signature
