Re: Allow disabling folding of unquoted identifiers to lowercase - Mailing list pgsql-general

From Guillaume Lelarge
Subject Re: Allow disabling folding of unquoted identifiers to lowercase
Date
Msg-id CAECtzeUAV6S2Ltxh1yzab-s6wzALmGR41YUVhJGqujTfkZDvfw@mail.gmail.com
Whole thread Raw
In response to Re: Allow disabling folding of unquoted identifiers to lowercase  (Evgeny Morozov <evgeny.morozov@shift-technology.com>)
List pgsql-general

Le 3 mai 2016 7:01 PM, "Evgeny Morozov" <evgeny.morozov@shift-technology.com> a écrit :
>
> That's an interesting idea! The client users would use is probably pgAdmin. I don't know whether pgAdmin parses the query, though. If it does then it should be relatively easy to add this. If not, I'd imagine it's not going to happen.
>

The pgAdmin query tool doesn't parse the query. It sends to the server without parsing itself.

> On 2 May 2016 at 13:59, John McKown <john.archie.mckown@gmail.com> wrote:
>>
>> On Mon, May 2, 2016 at 3:03 AM, Evgeny Morozov <evgeny.morozov+list+pgsql@shift-technology.com> wrote:
>>>
>>> On 30 April 2016 at 01:31, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>>>
>>>> Yeah, this isn't going to happen.  Years ago we looked into what it would
>>>> take to be able to flip a switch and have the standard-compliant behavior
>>>> (fold to upper not lower).  It was impractical then and no doubt is far
>>>> more so now.  I do not remember all the details, but there were multiple
>>>> pain points even in terms of server-side implementation, never mind all
>>>> the applications we'd break.
>>>
>>>
>>> Alright, thanks to everyone for looking into this. Not knowing the code, I naively assumed it should be easy to add an option to not do the case folding.
>>>  
>>>>
>>>>
>>>> What the OP is asking for doesn't even have the argument "but it's
>>>> standards compliant!" going for it. 
>>>>
>>> Indeed, my argument was it would allow people to choose their own naming convention to (easily) use with Postgres, which would in turn make it easier to migrate from other RDBMSes to Postgres. Although, if you want a standard compliance argument, that can easily be added. :) Just have 3 options: fold to lowercase (current behaviour, default), fold to uppercase (standards compliant), do not fold (most flexible, compatible with MSSQL and MySQL).
>>>
>>> > So I doubt we'd accept such a patch even if someone managed to create one.
>>>
>>> Well, I was going to ask if paying someone to fix this was an option, but this preempts that!
>>
>>
>> ​I have a silly idea. IIRC, your original problem is that your users are in the habit of entering something like:
>>
>> select ... from SomeTable ...
>>
>> And MySQL would actually use the name "SomeTable" (case preserving) and not "sometable" (PostgreSQL) or "SOMETABLE" (SQL standard). What program are the users actually using to do the select? If it is something like "psql", perhaps it would actually be easier to create a modified version which automatically inserts the " marks for them. Of course, you are now doing double parsing of the SQL. First in the client, to modify it before sending to the server. Then again in the server. OK, maybe it is going too far. I guess this might be a "quote everything which is not a keyword" option for a psql replacement. Or whatever the front end is that the users use.
>>
>>
>> --
>> The unfacts, did we have them, are too imprecisely few to warrant our certitude.
>>
>> Maranatha! <><
>> John McKown
>
>

pgsql-general by date:

Previous
From: Kurt Roeckx
Date:
Subject: Re: Very slow update / hash join
Next
From: Rafal Pietrak
Date:
Subject: Re: Debian and Postgres