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
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] |