Re: Alias hstore's ? to ~ so that it works with JDBC

From: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
To: Kris Jurka <books(at)ejurka(dot)com>
Cc: Dave Cramer <pg(at)fastcrypt(dot)com>, Seamus Abshere <seamus(at)abshere(dot)net>, Merlin Moncure <mmoncure(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Alias hstore's ? to ~ so that it works with JDBC
Date: 2013-02-11 19:35:08
Message-ID: 511947EC.4090104@vmware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 08.02.2013 19:41, Kris Jurka wrote:
> On Fri, 8 Feb 2013, Dave Cramer wrote:
>
>> Would this be an postgresql specific escape sequence ? I don't think the
>> spec allows for this does it ?
>>
>
> Yes, this would be a postgresql jdbc driver specific escape. The spec
> doesn't have a concept of private escape sequences, but that doesn't seem
> like the end of the world. Clearly the user here is writing postgresql
> specific code to use hstore operators, so there's not a portability loss
> here.

I agree it's pretty dumb that there's currently no such escape. I think
JDBC inherited that design mistake from ODBC. Fixing that would be a
good idea.

That said, it occurs to me that there's one fairly simple thing we could
also do in the backend. At the moment, unlike function and table names,
operators cannot be quoted. It would be easy to allow this in the grammar:

select 1 operator("+") 1;

The operator(...) syntax already exists, but the operator inside it
can't be quoted. It wouldn't create any conflicts to allow that.

- Heikki

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2013-02-11 19:49:51 Re: performance regression in 9.2 CTE with SRF function
Previous Message Andres Freund 2013-02-11 19:24:28 Re: Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]