On 25 December 2016 at 09:40, Lewis, Ian (Microstar Laboratories) <ile...@mstarlabs.com> wrote: > So, the current behavior already breaks many tools unless one accepts > that all symbols on the server are lower case. At root, based on reading > the threads you provided, this probably indicates defects in the tools, > rather than a problem with PostgreSQL. My reading of the standard text > quoted in various places is that any mixed case identifier returned from > the catalog has to be quoted to match in a query (whether you fold to > lower or upper case).
Well tools that work with user-defined columns and make assumptions that they don't require quoting are just buggy. But the problem with configurable quoting rules is a bit different. Imagine your application later decides to depend on PostGIS. So you load the PostGIS extension and perhaps also some useful functions you found on Stack Overflow for solving some GIS problem you have. Those extensions will create objects and then work with those objects and may use CamelCase for clarity -- in fact I think PostGIS functions are documented as CamelCase. The PostGIS extensions might not work on your system with different case rules if they haven't been 100% consistent with their camelCasing, and the functions from StackOverflow would be even less likely to work. If there was some way to scope this setting lexically so it only affected code that's defined in specific place that might be safer. But I don't think things are currently organized that way. If you're only concerned with server-side functions it wouldn't be hard to have a specific pl language that was case sensitive though it might be tricky to do to pl/pgsql due to the way pl/pgsql depends on the sql parser. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
