Re: case_preservation_and_insensitivity = on

On Thu, Feb 23, 2017 at 6:59 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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 think at least some requests for
this feature are intended at satisfying somebody's sense of
aesthetics. But I'll agree that the biggest use case is probably
porting applications from other systems. Even then, though, people
end up using PG-specific features as a way of working around stuff
that other systems support using different syntax - e.g. T-SQL that
works on SQL server might get turned into a DO block for PostgreSQL,
and it's surprising if that causes you to suddenly get different
case-folding rules. Also, people sometimes start by doing a port, and
then later start using PG-specific features, which introduces the same
kinds of problems.

> The odds that such an app uses DO
> blocks are exactly zero. It may well make use of server-side functions,
> but those are going to require significant porting effort in any case.
> So I think a case-folding function that could be interposed in front of
> libpq or JDBC or $favorite_driver could well go a long way towards solving
> that sort of problem. It wouldn't be 100%, sure, but if you hold your
> breath and wait for a 100% solution to appear on the server side, you're
> going to be quite blue.

True, but that doesn't make a leaky abstraction not a hack. It just
makes having a hack a practical improvement over not having one -- and
I'm perfectly happy to concede that hacks are sometimes useful.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company