On Feb 13, 2013 10:35 PM, "Heikki Linnakangas"
wrote:
> We could support operator("?") as well; belt and suspenders. That would
help ODBC clients too.
+1 for the belt and suspenders approach. With {postgres qm} JDBC can work
with older PostgreSQL versions, not requiring applications to bump their
On 13.02.2013 22:17, Kevin Grittner wrote:
Seamus Abshere wrote:
SELECT * FROM tbl WHERE data {postgres qm} 'abc'
That suggestion makes a lot of sense to me. The curly-brace
escapes are in JDBC for portability, so this seems like a totally
appropriate use; it's surprising it hasn't com
Seamus Abshere wrote:
> On 2/11/13 1:35 PM, Heikki Linnakangas wrote:
>> 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.
>
> Lance Anderson, Oracle's JDBC spec lead
Wow, there's a name I
On Feb 13, 2013 6:43 PM, "Alvaro Herrera" wrote:
>
> Seamus Abshere escribió:
>
> > [1]
http://mail.openjdk.java.net/pipermail/jdbc-spec-discuss/2013-February/58.html
> > [2]
http://mail.openjdk.java.net/pipermail/jdbc-spec-discuss/2013-February/date.html#51
> > (threaded view gets it out of o
Seamus Abshere escribió:
> [1]
> http://mail.openjdk.java.net/pipermail/jdbc-spec-discuss/2013-February/58.html
> [2]
> http://mail.openjdk.java.net/pipermail/jdbc-spec-discuss/2013-February/date.html#51
> (threaded view gets it out of order)
Ooh, how archaic --- they're still using Mhonarc
Since we already do escape processing much like c that might not be so
complex. However I haven't looked at the code, so I could be way off base.
The question I would pose is how palatable is it to use ? In other words is
it worth pursuing ?
Dave Cramer
dave.cramer(at)credativ(dot)ca
http://www.
On 2/11/13 1:35 PM, Heikki Linnakangas wrote:
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.
Lance Anderson, Oracle's JDBC spec lead, says [1] we can implement
something like:
SELECT
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 escap
On 2/11/13 11:30 AM, Tom Lane wrote:
It would take extremely deep knowledge of SQL syntax for the driver to
reliably tell the difference between a variable and an operator
Yes, auto-detecting the difference between bind vars and operators would
probably be even more difficult than providing es
Vladimir Sitnikov writes:
> The thing is PostgeSQL JDBC driver should be able to parse sql in order to
> tell if specific question mark is a bind variable or it is inside string
> literal, or it is inside of some comment.
What's your point? Those cases don't have anything to do with variables
ve
The thing is PostgeSQL JDBC driver should be able to parse sql in order to
tell if specific question mark is a bind variable or it is inside string
literal, or it is inside of some comment.
I do not believe JDBC spec forces to treat all ? as bind placeholders.
That's unusable.
Oracle JDBC allows h
That would seem to be the implication. JDBC wouldn't really know anything
about hstore.
Dave Cramer
dave.cramer(at)credativ(dot)ca
http://www.credativ.ca
On Fri, Feb 8, 2013 at 12:51 PM, Andrew Dunstan wrote:
>
> On 02/08/2013 12:41 PM, Kris Jurka wrote:
>
>>
>> On Fri, 8 Feb 2013, Dave Crame
On 02/08/2013 12:41 PM, 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 e
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 see
On Fri, Feb 8, 2013 at 11:43 AM, Kris Jurka wrote:
>
>
> On Wed, 6 Feb 2013, Seamus Abshere wrote:
>
> > I personally don't know of any way around the conflict except changing
> > JDBC or hstore, and I don't think JDBC is gonna change.
> >
>
> I think changing JDBC is the way to go. Currently JD
On Wed, 6 Feb 2013, Seamus Abshere wrote:
> I personally don't know of any way around the conflict except changing
> JDBC or hstore, and I don't think JDBC is gonna change.
>
I think changing JDBC is the way to go. Currently JDBC supports escape
sequences for cross database portability and
merlin,
I appreciate your perspective and wish that JDBC didn't present this
problem. Still, with the rapidly growing adoption of both Postgres and
JVM-based languages (thanks Heroku!) - plus the special power of hstore
- I think it would be a shame if such a small accommodation could not be
merlin,
Yes, you're correct, my phrasing was bad: all I meant was that it was a
conflict, not a bug in Postgres or hstore.
I personally don't know of any way around the conflict except changing
JDBC or hstore, and I don't think JDBC is gonna change.
Deciding not to accommodate JDBC on the P
On Wed, Feb 6, 2013 at 11:42 PM, Merlin Moncure wrote:
> >> *) hacking pg_operator (carefully look up and change oprname for the
> >> specific hstore operator)
> >
> >
> > bad solution. Why not just provide an additional operator?
> >
> >CREATE OPERATOR ~ (
> > LEFTARG = hstore,
> >
tl;dr
Scala/JRuby/Clojure (any JVM-based language) + Postgres + hstore =
awesome... why not just add a few lines to hstore--1.2.sql and make sure
that all operators are available and indexable?
hi Andrew, hi merlin,
use the existing "exist()" function
EXIST() can't use hstore's GiST or GI
On Wed, Feb 6, 2013 at 12:00 PM, Andrew Dunstan wrote:
>
> On 02/06/2013 12:34 PM, Merlin Moncure wrote:
>>
>>
>> The point is that Postgres should not introduce language constraints
>> because of broken driver technology.
>
>
> +1
>
>
>> To move forward in your
>> particular case, consider:
>> *)
On 02/06/2013 12:34 PM, Merlin Moncure wrote:
The point is that Postgres should not introduce language constraints
because of broken driver technology.
+1
To move forward in your
particular case, consider:
*) switching to 'hstore defined()' function:
good solution - but just use the exist
On Wed, Feb 6, 2013 at 11:20 AM, Seamus Abshere wrote:
> merlin,
>
> Yes, you're correct, my phrasing was bad: all I meant was that it was a
> conflict, not a bug in Postgres or hstore.
>
> I personally don't know of any way around the conflict except changing JDBC
> or hstore, and I don't think J
On Tue, Feb 5, 2013 at 11:29 AM, Seamus Abshere wrote:
> hi,
>
> As reported in BUG #7715 [1], hstore's use of ? as an operator conflicts
> with JDBC's bind variables.
>
> I think we could just alias ? to ~ and tell JDBC users to use that instead.
> [2]
This is not a bug with postgres, but with j
hi,
As reported in BUG #7715 [1], hstore's use of ? as an operator conflicts
with JDBC's bind variables.
I think we could just alias ? to ~ and tell JDBC users to use that
instead. [2]
Best,
Seamus
[1]
http://www.postgresql.org/message-id/e1teiju-0003qb...@wrigleys.postgresql.org
[2] htt
25 matches
Mail list logo