Re: [HACKERS] case_preservation_and_insensitivity = on

2017-02-25 Thread Robert Haas
On Fri, Feb 24, 2017 at 11:04 PM, Joel Jacobson wrote: > On Thu, Feb 23, 2017 at 8:04 AM, Robert Haas wrote: >> It doesn't sound like a good solution to me, because there can be SQL >> code inside stored procedures that clients never see. > > In our code

Re: [HACKERS] case_preservation_and_insensitivity = on

2017-02-24 Thread Gavin Flower
On 25/02/17 09:02, Jim Nasby wrote: On 2/24/17 12:28 AM, Robert Haas wrote: On Thu, Feb 23, 2017 at 6:59 PM, Tom Lane wrote: I think these are straw-man arguments, really. Consider the actual use case for such a feature: it's for porting some application that was not

Re: [HACKERS] case_preservation_and_insensitivity = on

2017-02-24 Thread Jim Nasby
On 2/24/17 12:28 AM, Robert Haas wrote: On Thu, Feb 23, 2017 at 6:59 PM, Tom Lane wrote: I think these are straw-man arguments, really. Consider the actual use case for such a feature: it's for porting some application that was not written against Postgres to begin with.

Re: [HACKERS] case_preservation_and_insensitivity = on

2017-02-24 Thread Jim Nasby
On 2/24/17 11:34 AM, Joel Jacobson wrote: SELECT SomeCol, OtherCol, FooCol, BarCol, MyCol, ExtraCol, LastCol INTO _SomeCol, _OtherCol, _FooCol, _BarCol, _MyCol, _ExtraCol, _LastCol FROM Foo WHERE Bar = 'Baz'; This is to avoid typos that are then visually easy to spot, thanks to

Re: [HACKERS] case_preservation_and_insensitivity = on

2017-02-24 Thread Joel Jacobson
On Thu, Feb 23, 2017 at 8:04 AM, Robert Haas wrote: > > It doesn't sound like a good solution to me, because there can be SQL > code inside stored procedures that clients never see. In our code base, we use CamelCase in all PL/pgSQL functions, both for columns and

Re: [HACKERS] case_preservation_and_insensitivity = on

2017-02-23 Thread Robert Haas
On Thu, Feb 23, 2017 at 6:59 PM, Tom Lane wrote: > I think these are straw-man arguments, really. Consider the actual use > case for such a feature: it's for porting some application that was not > written against Postgres to begin with. I'm not sure that's totally true. I

Re: [HACKERS] case_preservation_and_insensitivity = on

2017-02-23 Thread Tom Lane
Robert Haas writes: > On Mon, Feb 20, 2017 at 3:06 PM, Joel Jacobson wrote: >> On Mon, Feb 20, 2017 at 1:45 AM, Tom Lane wrote: >>> The versions of autocommit that have actually stood the test of time were >>> implemented on the

Re: [HACKERS] case_preservation_and_insensitivity = on

2017-02-22 Thread Robert Haas
On Mon, Feb 20, 2017 at 3:06 PM, Joel Jacobson wrote: > On Mon, Feb 20, 2017 at 1:45 AM, Tom Lane wrote: >> The versions of autocommit that have actually stood the test of time were >> implemented on the client side (in psql and JDBC, and I think ODBC as >>

Re: [HACKERS] case_preservation_and_insensitivity = on

2017-02-22 Thread Jim Nasby
On 2/20/17 3:30 AM, Joel Jacobson wrote: Also, I think the --lowercase-uniqueness feature would be useful by itself even without the --case-preserving feature, since that might be a good way to enforce a good design of new databases, as a mix of "users" and "Users" is probably considered ugly by

Re: [HACKERS] case_preservation_and_insensitivity = on

2017-02-20 Thread Joel Jacobson
On Mon, Feb 20, 2017 at 1:45 AM, Tom Lane wrote: > The versions of autocommit that have actually stood the test of time were > implemented on the client side (in psql and JDBC, and I think ODBC as > well), where the scope of affected code was lots smaller. I wonder > whether

Re: [HACKERS] case_preservation_and_insensitivity = on

2017-02-20 Thread Joel Jacobson
On Mon, Feb 20, 2017 at 2:40 AM, Jim Nasby wrote: > Even if the project decided that "Users" and users is stupid and that we > should deprecate it, I think the odds of also deciding to tell existing > users to re-write their apps are zero. But if the feature can't be

Re: [HACKERS] case_preservation_and_insensitivity = on

2017-02-19 Thread Tom Lane
Joel Jacobson writes: > I think a good general philosophy for the PostgreSQL project would be to > try to look at how to meed the needs for new users of new projects > in a way that don't impair things for existing users, Yeah, exactly, and the problem here is that claiming

Re: [HACKERS] case_preservation_and_insensitivity = on

2017-02-19 Thread Jim Nasby
On 2/19/17 4:51 PM, Joel Jacobson wrote: But once you've already decided to have a hard-and-fast rule that the names must be unique after lower-casing, there's no obvious benefit to rejecting queries that mention the same name with different case. Exactly, that trade-off is necessary, otherwise

Re: [HACKERS] case_preservation_and_insensitivity = on

2017-02-19 Thread Joel Jacobson
On Sun, Feb 19, 2017 at 5:58 PM, Robert Haas wrote: >> When case preservation by default is on, then simply enforce >> UNIQUE(LOWER(object_name)), to prevent ambiguity. > > That (1) breaks backward compatibility, because people might have > objects with names identical

Re: [HACKERS] case_preservation_and_insensitivity = on

2017-02-19 Thread Robert Haas
On Thu, Feb 16, 2017 at 11:16 PM, Joel Jacobson wrote: >> The short answer is that nobody can see a way to modify the identifier >> case-folding rules that isn't going to add more pain than it subtracts. >> And much of the added pain will be felt by people who aren't getting >>

Re: [HACKERS] case_preservation_and_insensitivity = on

2017-02-16 Thread Joel Jacobson
On Thu, Feb 16, 2017 at 6:53 AM, Tom Lane wrote: > Have you read any of our innumerable previous discussions about this? No, sorry, didn't see them, thanks for sharing the links. > The short answer is that nobody can see a way to modify the identifier > case-folding rules

Re: [HACKERS] case_preservation_and_insensitivity = on

2017-02-15 Thread Tom Lane
Joel Jacobson writes: > Case Preservation + Case Insensitivity = A good combination > Thoughts? Have you read any of our innumerable previous discussions about this? The last one was barely a month ago, cf