On 03/06/2014 12:58 PM, Daniele Varrazzo wrote:
On Thu, Mar 6, 2014 at 6:54 PM, Josh Berkus j...@agliodbs.com wrote:
The actual storage upgrade of hstore--hstore2 is fairly painless from
the user perspective; they don't have to do anything. The problem is
that the input/output strings are
On Thu, Mar 6, 2014 at 09:50:56PM +0400, Oleg Bartunov wrote:
Hi there,
Looks like consensus is done. I and Teodor are not happy with it, but
what we can do :) One thing I want to do is to reserve our
contribution to the flagship feature (jsonb), particularly, binary
storage for nested
On Thu, Mar 6, 2014 at 04:33:08PM +0100, Ronan Dunklau wrote:
I'm not sure what the constraints of json that you might want to break
are. Perhaps you'd like to specify.
I haven't followed the whole thread, but json is really restrictive on the
supported types: a hierarchical hstore could
On Mon, Mar 3, 2014 at 06:59:37PM -0800, Josh Berkus wrote:
Realistically, hstore will never go away. I'll bet you a round or two
of pints that, if we get both hstore2 and jsonb, within 2 years the
users of jsonb will be an order of magnitude more numerous that then
users of hstore, but
On 03/05/2014 09:39 AM, Bruce Momjian wrote:
So, I am going to ask a back-track question and ask why we can't move
hstore into core. Is this a problem with the oids of the hstore data
type and functions? Is this a pg_upgrade-only problem? Can this be
fixed?
Yes, pg_upgrade is the
On Wed, Mar 5, 2014 at 8:39 AM, Bruce Momjian br...@momjian.us wrote:
So, I am going to ask a back-track question and ask why we can't move
hstore into core.
This is exactly the opposite of what should be happening. Now, jsonb
might make it into core because of the json precedent but the
Andrew Dunstan and...@dunslane.net writes:
On 03/05/2014 09:39 AM, Bruce Momjian wrote:
So, I am going to ask a back-track question and ask why we can't move
hstore into core. Is this a problem with the oids of the hstore data
type and functions? Is this a pg_upgrade-only problem? Can this
On Wed, Mar 5, 2014 at 9:24 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net writes:
On 03/05/2014 09:39 AM, Bruce Momjian wrote:
So, I am going to ask a back-track question and ask why we can't move
hstore into core. Is this a problem with the oids of the hstore data
On 03/05/2014 10:24 AM, Tom Lane wrote:
Also, there might be other cases besides arrays where we've embedded
type OIDs in on-disk data; anyone remember?
Don't we do that in composites too?
cheers
andrew
--
Sent via pgsql-hackers mailing list
Merlin Moncure mmonc...@gmail.com writes:
On Wed, Mar 5, 2014 at 9:24 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Also, there might be other cases besides arrays where we've embedded
type OIDs in on-disk data; anyone remember?
composite types.
But that's only the composite type's own OID, no? So
On 03/05/2014 10:30 AM, Tom Lane wrote:
Merlin Moncure mmonc...@gmail.com writes:
On Wed, Mar 5, 2014 at 9:24 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Also, there might be other cases besides arrays where we've embedded
type OIDs in on-disk data; anyone remember?
composite types.
But that's
On Wed, Mar 5, 2014 at 09:19:33AM -0600, Merlin Moncure wrote:
On Wed, Mar 5, 2014 at 8:39 AM, Bruce Momjian br...@momjian.us wrote:
So, I am going to ask a back-track question and ask why we can't move
hstore into core.
This is exactly the opposite of what should be happening. Now,
On Wed, Mar 5, 2014 at 10:19 AM, Merlin Moncure mmonc...@gmail.com wrote:
On Wed, Mar 5, 2014 at 8:39 AM, Bruce Momjian br...@momjian.us wrote:
So, I am going to ask a back-track question and ask why we can't move
hstore into core.
This is exactly the opposite of what should be happening.
Robert Haas robertmh...@gmail.com writes:
And despite the assertions from various people here that these
decisions were all made a long time ago and it's way too late to
question them, I don't buy it. There's not a single email on this
mailing list clearly laying out the design that we've
On Wed, Mar 5, 2014 at 10:39:56AM -0500, Andrew Dunstan wrote:
On 03/05/2014 10:30 AM, Tom Lane wrote:
Merlin Moncure mmonc...@gmail.com writes:
On Wed, Mar 5, 2014 at 9:24 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Also, there might be other cases besides arrays where we've embedded
type OIDs
On Wed, Mar 5, 2014 at 9:52 AM, Bruce Momjian br...@momjian.us wrote:
On Wed, Mar 5, 2014 at 09:19:33AM -0600, Merlin Moncure wrote:
On Wed, Mar 5, 2014 at 8:39 AM, Bruce Momjian br...@momjian.us wrote:
So, I am going to ask a back-track question and ask why we can't move
hstore into core.
On Mon, Mar 3, 2014 at 11:20 PM, Peter Geoghegan p...@heroku.com wrote:
On Mon, Mar 3, 2014 at 6:59 PM, Josh Berkus j...@agliodbs.com wrote:
Also, please recognize that the current implementation was what we
collectively decided on three months ago, and what Andrew worked pretty
hard to
Bruce Momjian br...@momjian.us writes:
It seems only pg_type.oid is an issue for hstore. We can easily modify
pg_dump --binary-upgrade mode to suppress the creation of the hstore
extension. That should allow user hstore columns to automatically map
to the new constant hstore oid. We can
On 2014-03-05 10:10:23 -0600, Merlin Moncure wrote:
On Wed, Mar 5, 2014 at 9:52 AM, Bruce Momjian br...@momjian.us wrote:
On Wed, Mar 5, 2014 at 09:19:33AM -0600, Merlin Moncure wrote:
*All* non-sql standard types ought to be in extensions in an ideal world.
I have seen your opinion on
Merlin Moncure mmonc...@gmail.com writes:
*All* non-sql standard types ought to be in extensions in an ideal world.
While there's certainly much to be said for the idea that jsonb should be
an extension, I don't think we have the technology to package it as a
*separate* extension; it'd have to
On Wed, Mar 5, 2014 at 10:19 AM, Andres Freund and...@2ndquadrant.com wrote:
There's the absolutely significant issue that you cannot reasonably
write extensions that interact on a C level. You can't call from
extension to extension directly, but you can from extension to pg core
provided
* Merlin Moncure (mmonc...@gmail.com) wrote:
*All* non-sql standard types ought to be in extensions in an ideal world.
While I appreciate that you'd like to see it that way, others don't
agree (I certainly don't), and that ship sailed quite a long time ago
regardless. I'm not advocating putting
On Wed, Mar 5, 2014 at 11:07 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
And despite the assertions from various people here that these
decisions were all made a long time ago and it's way too late to
question them, I don't buy it. There's not a single
On Wed, Mar 5, 2014 at 11:24 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Merlin Moncure mmonc...@gmail.com writes:
*All* non-sql standard types ought to be in extensions in an ideal world.
While there's certainly much to be said for the idea that jsonb should be
an extension, I don't think we have
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Just out of curiosity, exactly what features are missing from jsonb
today that are available with hstore? How long would it take to
copy-and-paste all that code, if someone were to decide to do the
work instead of argue about it?
Somewhere upthread,
On Wed, Mar 5, 2014 at 10:24 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Merlin Moncure mmonc...@gmail.com writes:
*All* non-sql standard types ought to be in extensions in an ideal world.
While there's certainly much to be said for the idea that jsonb should be
an extension, I don't think we have
* Merlin Moncure (mmonc...@gmail.com) wrote:
On Wed, Mar 5, 2014 at 10:24 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Merlin Moncure mmonc...@gmail.com writes:
*All* non-sql standard types ought to be in extensions in an ideal world.
While there's certainly much to be said for the idea that
On Wed, Mar 5, 2014 at 11:16:01AM -0500, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
It seems only pg_type.oid is an issue for hstore. We can easily modify
pg_dump --binary-upgrade mode to suppress the creation of the hstore
extension. That should allow user hstore columns to
On 03/05/2014 11:34 AM, Stephen Frost wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Just out of curiosity, exactly what features are missing from jsonb
today that are available with hstore? How long would it take to
copy-and-paste all that code, if someone were to decide to do the
work
On Wed, Mar 5, 2014 at 11:34:10AM -0500, Stephen Frost wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Just out of curiosity, exactly what features are missing from jsonb
today that are available with hstore? How long would it take to
copy-and-paste all that code, if someone were to decide
On Wed, Mar 5, 2014 at 11:11:51AM -0500, Robert Haas wrote:
An excellent question. This thread has become mostly about whether
someone (like, say, me, or in this case Peter) is attempting to pull
the rug out from under a previously-agreed consensus path forward.
But despite my asking,
On 03/05/2014 11:44 AM, Bruce Momjian wrote:
On Wed, Mar 5, 2014 at 11:16:01AM -0500, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
It seems only pg_type.oid is an issue for hstore. We can easily modify
pg_dump --binary-upgrade mode to suppress the creation of the hstore
extension.
On Wed, Mar 5, 2014 at 10:43 AM, Stephen Frost sfr...@snowman.net wrote:
* Merlin Moncure (mmonc...@gmail.com) wrote:
On Wed, Mar 5, 2014 at 10:24 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Merlin Moncure mmonc...@gmail.com writes:
*All* non-sql standard types ought to be in extensions in an
On Wed, Mar 5, 2014 at 11:53:31AM -0500, Andrew Dunstan wrote:
I think we also have to break out how much of the feeling that JSONB is
not ready is because of problems with the core/contrib split, and how
much of it is because of the type itself. I am suggesting that
core/contrib split
On Mar 5, 2014, at 8:49 AM, Andrew Dunstan and...@dunslane.net wrote:
I think that was my estimate, but Peter did offer to do it. He certainly
asserted that the effort required would not be great. I'm all for taking up
his offer.
+1 to this. Can you and Peter collaborate somehow to get it
Merlin Moncure mmonc...@gmail.com writes:
On Wed, Mar 5, 2014 at 10:24 AM, Tom Lane t...@sss.pgh.pa.us wrote:
While there's certainly much to be said for the idea that jsonb should be
an extension, I don't think we have the technology to package it as a
*separate* extension; it'd have to be
On Wed, Mar 5, 2014 at 11:50 AM, Bruce Momjian br...@momjian.us wrote:
On Wed, Mar 5, 2014 at 11:34:10AM -0500, Stephen Frost wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Just out of curiosity, exactly what features are missing from jsonb
today that are available with hstore? How long
* Robert Haas (robertmh...@gmail.com) wrote:
On Wed, Mar 5, 2014 at 11:50 AM, Bruce Momjian br...@momjian.us wrote:
What _would_ be interesting is to move all the hstore code into core,
and have hstore contrib just call the hstore core parts. That way, you
have one copy of the code, it is
On Wed, Mar 5, 2014 at 12:26:13PM -0500, Robert Haas wrote:
It's not clear how much different it would be if we waited til 9.5
either- do we anticipate a lot of code changes beyond the copy/paste for
these?
What _would_ be interesting is to move all the hstore code into core,
and have
On 03/05/2014 12:01 PM, Bruce Momjian wrote:
On Wed, Mar 5, 2014 at 11:53:31AM -0500, Andrew Dunstan wrote:
I think we also have to break out how much of the feeling that JSONB is
not ready is because of problems with the core/contrib split, and how
much of it is because of the type itself.
* Merlin Moncure (mmonc...@gmail.com) wrote:
On Wed, Mar 5, 2014 at 10:43 AM, Stephen Frost sfr...@snowman.net wrote:
Yeah, from what I gather you're suggesting, that's more-or-less move it
all to core, except that all of the actual interface bits end up in an
extension that has to be
On Wed, Mar 5, 2014 at 11:19 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Merlin Moncure mmonc...@gmail.com writes:
On Wed, Mar 5, 2014 at 10:24 AM, Tom Lane t...@sss.pgh.pa.us wrote:
While there's certainly much to be said for the idea that jsonb should be
an extension, I don't think we have the
On 03/05/2014 09:26 AM, Robert Haas wrote:
What _would_ be interesting is to move all the hstore code into core,
and have hstore contrib just call the hstore core parts. That way, you
have one copy of the code, it is shared with JSONB, but hstore remains
as an extension that you can
On Wed, Mar 5, 2014 at 8:30 AM, Robert Haas robertmh...@gmail.com wrote:
Just out of curiosity, exactly what features are missing from jsonb
today that are available with hstore? How long would it take to
copy-and-paste all that code, if someone were to decide to do the
work instead of argue
On Wed, Mar 5, 2014 at 10:59:37AM -0800, Peter Geoghegan wrote:
On Wed, Mar 5, 2014 at 8:30 AM, Robert Haas robertmh...@gmail.com wrote:
Just out of curiosity, exactly what features are missing from jsonb
today that are available with hstore? How long would it take to
copy-and-paste all
On 03/05/2014 11:05 AM, Bruce Momjian wrote:
Can you clarify what hstore2 is? It that the name of a type? Is that
hierarchical hstore with the same hstore name?
hstore2 == nested heirarchical hstore. It's just a shorthand; there
won't be any actual type called hstore2, by design. Unlike the
On Wed, Mar 5, 2014 at 10:59:37AM -0800, Peter Geoghegan wrote:
On Wed, Mar 5, 2014 at 8:30 AM, Robert Haas robertmh...@gmail.com wrote:
Just out of curiosity, exactly what features are missing from jsonb
today that are available with hstore? How long would it take to
copy-and-paste all
On Wed, Mar 5, 2014 at 11:44 AM, Stephen Frost sfr...@snowman.net wrote:
* Merlin Moncure (mmonc...@gmail.com) wrote:
On Wed, Mar 5, 2014 at 10:43 AM, Stephen Frost sfr...@snowman.net wrote:
Yeah, from what I gather you're suggesting, that's more-or-less move it
all to core, except that all
* Merlin Moncure (mmonc...@gmail.com) wrote:
On Wed, Mar 5, 2014 at 11:44 AM, Stephen Frost sfr...@snowman.net wrote:
We have backwards compatibility problems because we don't want to
*break* things for people. Moving things into extensions doesn't
magically fix that- if you break
Merlin Moncure escribió:
On Wed, Mar 5, 2014 at 11:44 AM, Stephen Frost sfr...@snowman.net wrote:
We have backwards compatibility problems because we don't want to
*break* things for people. Moving things into extensions doesn't
magically fix that- if you break something in a
On Wed, Mar 5, 2014 at 2:45 PM, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
Merlin Moncure escribió:
It doesn't magically fix it, but at least provides a way forward. If
the function you want to modify is in an extension 'foo', you get to
put your new stuff in 'foo2' extension. That way
* Merlin Moncure (mmonc...@gmail.com) wrote:
On Wed, Mar 5, 2014 at 2:46 PM, Stephen Frost sfr...@snowman.net wrote:
I don't see why we can't do exactly what you're suggesting in core.
Because you can't (if you're defining core to mean 'not an
extension'). Functions can't be removed or
On Wed, Mar 5, 2014 at 4:24 PM, Stephen Frost sfr...@snowman.net wrote:
* Merlin Moncure (mmonc...@gmail.com) wrote:
On Wed, Mar 5, 2014 at 2:46 PM, Stephen Frost sfr...@snowman.net wrote:
I don't see why we can't do exactly what you're suggesting in core.
Because you can't (if you're
On Wed, Mar 5, 2014 at 11:32 AM, Bruce Momjian br...@momjian.us wrote:
So, now knowing that hstore2 is just hierarchical hstore using the same
hstore type name, you are saying that we are keeping the
non-hierarchical code in contrib, and the rest goes into core --- that
makes sense, and from a
On 03/05/2014 09:07 PM, Peter Geoghegan wrote:
It's hard to justify having a user-facing hstore2 on the grounds of
backwards compatibility, and giving those stuck on hstore the benefit
of all of these new capabilities. That's because we *cannot* really
preserve compatibility, AFAICT. Many of
Hi Oleg,
On Mon, Mar 3, 2014 at 7:17 AM, Oleg Bartunov obartu...@gmail.com wrote:
you can always look at our development repository:
I think I found a bug:
[local]/postgres=# \d+ bar
Table public.bar
Column | Type | Modifiers | Storage | Stats target | Description
Thanks, looks like a bug.
On Tue, Mar 4, 2014 at 12:38 PM, Peter Geoghegan p...@heroku.com wrote:
Hi Oleg,
On Mon, Mar 3, 2014 at 7:17 AM, Oleg Bartunov obartu...@gmail.com wrote:
you can always look at our development repository:
I think I found a bug:
[local]/postgres=# \d+ bar
On Tue, Mar 4, 2014 at 1:30 AM, Oleg Bartunov obartu...@gmail.com wrote:
Thanks, looks like a bug.
I guess this is down to the continued definition of gin_hstore_ops as
an opclass with text storage?:
+ CREATE OPERATOR CLASS gin_hstore_ops
+ DEFAULT FOR TYPE hstore USING gin
+ AS
+
I guess this is down to the continued definition of gin_hstore_ops as
an opclass with text storage?:
No, type of this storage describes type of keys. For gin_hstore_ops each key and
each value will be stored as a text value. The root of problem is a JavaScript
or/and our numeric type. In
select '{a: 25}'::json-'a' = '{a: 25.0}'::json-'a';
?column?
--
f
Although for development version of hstore (not a current version)
# select 'a= 25'::hstore = 'a= 25.0'::hstore;
?column?
--
t
That is because compareJsonbValue compares numeric values with a help of
On Tue, Mar 4, 2014 at 2:07 AM, Teodor Sigaev teo...@sigaev.ru wrote:
No, type of this storage describes type of keys. For gin_hstore_ops each key
and each value will be stored as a text value. The root of problem is a
JavaScript or/and our numeric type. In JavaScript (which was a base for json
On Tue, Mar 4, 2014 at 2:18 AM, Teodor Sigaev teo...@sigaev.ru wrote:
That is because compareJsonbValue compares numeric values with a help of
numeric_cmp() instead of comparing text representation. This inconsistent
will be fixed.
Cool.
--
Peter Geoghegan
--
Sent via pgsql-hackers
On Tue, Mar 4, 2014 at 2:18 AM, Peter Geoghegan p...@heroku.com wrote:
On Tue, Mar 4, 2014 at 2:18 AM, Teodor Sigaev teo...@sigaev.ru wrote:
That is because compareJsonbValue compares numeric values with a help of
numeric_cmp() instead of comparing text representation. This inconsistent
will
I tried try.mongodb.com
25 == 25.0
true
On Tue, Mar 4, 2014 at 2:18 PM, Peter Geoghegan p...@heroku.com wrote:
On Tue, Mar 4, 2014 at 2:18 AM, Teodor Sigaev teo...@sigaev.ru wrote:
That is because compareJsonbValue compares numeric values with a help of
numeric_cmp() instead of comparing
Do we have function to trim right zeros in numeric?
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
On Tue, Mar 4, 2014 at 2:44 AM, Teodor Sigaev teo...@sigaev.ru wrote:
Do we have function to trim right zeros in numeric?
I'm not sure why you ask. I hope it isn't because you want to fix this
bug by making text comparisons in place of numeric comparisons work by
fixing the exact problem I
On Tue, Mar 4, 2014 at 2:44 AM, Teodor Sigaev teo...@sigaev.ru wrote:
Do we have function to trim right zeros in numeric?
Fixed, pushed to github
(https://github.com/feodor/postgres/tree/jsonb_and_hstore). Now it used
hash_numeric to index numeric value. As I can see, it provides needed
On Tue, Mar 4, 2014 at 6:48 AM, Teodor Sigaev teo...@sigaev.ru wrote:
On Tue, Mar 4, 2014 at 2:44 AM, Teodor Sigaev teo...@sigaev.ru wrote:
Do we have function to trim right zeros in numeric?
Fixed, pushed to github
(https://github.com/feodor/postgres/tree/jsonb_and_hstore). Now it used
huh. what it is the standard for equivalence? I guess we'd be
following javascript ===, right?
(http://dorey.github.io/JavaScript-Equality-Table/).
right.
But in your link I don't understand array (and object) equality rules. Hstore
(and jsonb) compare function believes that arrays are
On 03/03/2014 09:06 PM, Peter Geoghegan wrote:
On Mon, Mar 3, 2014 at 9:05 PM, Andrew Dunstan and...@dunslane.net wrote:
What you're not welcome to do, from my POV, is move jsonb into the hstore
extension. I strenuously object to any such plan.
We both know that that isn't really the point
On Fri, Feb 28, 2014 at 2:01 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-02-28 14:45:29 -0500, Andrew Dunstan wrote:
Well, the jsonb portion of this is arguably the most ready, certainly it's
had a lot more on-list review.
Having crossread both patches I tend to agree with this. I
On 2014-03-03 08:57:59 -0600, Merlin Moncure wrote:
On Fri, Feb 28, 2014 at 2:01 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-02-28 14:45:29 -0500, Andrew Dunstan wrote:
Well, the jsonb portion of this is arguably the most ready, certainly it's
had a lot more on-list review.
Andres,
you can always look at our development repository:
https://github.com/feodor/postgres/tree/hstore - hstore only,
https://github.com/feodor/postgres/tree/jsonb_and_hstore - hstore with jsonb
Since we were concentrated on the jsonb_and_hstore branch we usually
wait Andrew, who publish
Hi Oleg,
On 2014-03-03 19:17:12 +0400, Oleg Bartunov wrote:
Since we were concentrated on the jsonb_and_hstore branch we usually
wait Andrew, who publish patch. You last issues were addressed in
both branches.
I'll try to have look sometime soon.
We are not native-english and may not well
On Mon, Mar 3, 2014 at 7:22 PM, Andres Freund and...@2ndquadrant.com wrote:
Hi Oleg,
On 2014-03-03 19:17:12 +0400, Oleg Bartunov wrote:
Since we were concentrated on the jsonb_and_hstore branch we usually
wait Andrew, who publish patch. You last issues were addressed in
both branches.
On 04/03/14 04:25, Oleg Bartunov wrote:
On Mon, Mar 3, 2014 at 7:22 PM, Andres Freund and...@2ndquadrant.com wrote:
[...]
PS: Not a native speaker either...
That's explain all :)
[...]
I AM a native English speaker born in England - though if you read some
of my postings where I've been
On Fri, Feb 28, 2014 at 2:12 PM, Peter Geoghegan p...@heroku.com wrote:
In order to make a rational decision to do the work incrementally, we
need to know what we're putting off until 9.5. AFAICT, we have these
operator classes that work fine with jsonb for the purposes of
hstore-style
On 03/03/2014 04:50 PM, Peter Geoghegan wrote:
I understand that there are ambitious plans for a VODKA-am that will
support indexing operations on nested structures that are a lot more
advanced than those enabled by the hstore operator classes included in
these patches. However, surely these
On Mon, Mar 3, 2014 at 4:57 PM, Josh Berkus j...@agliodbs.com wrote:
On 03/03/2014 04:50 PM, Peter Geoghegan wrote:
I understand that there are ambitious plans for a VODKA-am that will
support indexing operations on nested structures that are a lot more
advanced than those enabled by the
On 03/03/2014 05:07 PM, Peter Geoghegan wrote:
Primary value is that in theory the hstore2 opclasses are available
*now*, as opposed to a year from now.
Well, yes, that's right. Although we cannot assume that VODKA will get
into 9.5 - it's a big project. Nor is it obvious to me that a
On Mon, Mar 3, 2014 at 5:09 PM, Josh Berkus j...@agliodbs.com wrote:
On 03/03/2014 05:07 PM, Peter Geoghegan wrote:
Primary value is that in theory the hstore2 opclasses are available
*now*, as opposed to a year from now.
Well, yes, that's right. Although we cannot assume that VODKA will get
On 03/03/2014 07:50 PM, Peter Geoghegan wrote:
On Fri, Feb 28, 2014 at 2:12 PM, Peter Geoghegan p...@heroku.com wrote:
In order to make a rational decision to do the work incrementally, we
need to know what we're putting off until 9.5. AFAICT, we have these
operator classes that work fine with
On 03/03/2014 06:17 PM, Peter Geoghegan wrote:
Good. Hopefully you also mean that you recognize the dilemma referred
to above - that the hstore code reuse made a certain amount of sense,
and that more than likely the best way forward is to work out a way to
make it work. I'm not immediately
On Mon, Mar 3, 2014 at 6:54 PM, Andrew Dunstan and...@dunslane.net wrote:
My aim for 9.4, given constraints of both the development cycle and my time
budget, has been to get jsonb to a point where it has equivalent
functionality to json, so that nobody is forced to say well I'll have to
use
On Mon, Mar 3, 2014 at 7:39 PM, Peter Geoghegan p...@heroku.com wrote:
But that's really just a start. Frankly, I think we need to
think a lot harder about how we want to be able to index this sort of data.
The proposed hstore operators appear to me to be at best just scratching the
surface of
On Mon, Mar 3, 2014 at 6:59 PM, Josh Berkus j...@agliodbs.com wrote:
Also, please recognize that the current implementation was what we
collectively decided on three months ago, and what Andrew worked pretty
hard to implement based on that collective decision. So if we're going
to change
On 03/03/2014 10:39 PM, Peter Geoghegan wrote:
On Mon, Mar 3, 2014 at 6:54 PM, Andrew Dunstan and...@dunslane.net wrote:
My aim for 9.4, given constraints of both the development cycle and my time
budget, has been to get jsonb to a point where it has equivalent
functionality to json, so that
On 03/03/2014 11:20 PM, Peter Geoghegan wrote:
On Mon, Mar 3, 2014 at 6:59 PM, Josh Berkus j...@agliodbs.com wrote:
Also, please recognize that the current implementation was what we
collectively decided on three months ago, and what Andrew worked pretty
hard to implement based on that
On Mon, Mar 3, 2014 at 9:05 PM, Andrew Dunstan and...@dunslane.net wrote:
What you're not welcome to do, from my POV, is move jsonb into the hstore
extension. I strenuously object to any such plan.
We both know that that isn't really the point of contention at all.
--
Peter Geoghegan
--
On Mon, Mar 3, 2014 at 8:59 PM, Andrew Dunstan and...@dunslane.net wrote:
Okay, that's fine. I'm sure that jsonb has some value without
hstore-style indexing. That isn't really in question. What is in
question is why you would choose to give up on those capabilities.
Who has given up?
I
On 2014-02-27 23:54:47 -0800, Peter Geoghegan wrote:
In any case, as I say, if that's the patch that Andres or Oleg or
Teodor really want to submit, then by all means let them submit it.
Just to make that clear, I am not one of the authors, I just did a
couple of light review passes.
On Fri, Feb 28, 2014 at 12:01 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-02-27 23:54:47 -0800, Peter Geoghegan wrote:
In any case, as I say, if that's the patch that Andres or Oleg or
Teodor really want to submit, then by all means let them submit it.
Just to make that clear, I
On 2014-02-27 15:06:33 -0500, Andrew Dunstan wrote:
You realize that this API dates from 9.3 and has been used in numerous
extensions, right? So the names are pretty well fixed, for good or ill.
Sure. Doesn't prevent adding a couple more comments tho. I've only
noticed this because I opened the
On 28 February 2014 08:12, Andres Freund and...@2ndquadrant.com wrote:
On 2014-02-27 15:06:33 -0500, Andrew Dunstan wrote:
You realize that this API dates from 9.3 and has been used in numerous
extensions, right? So the names are pretty well fixed, for good or ill.
Sure. Doesn't prevent
On 28 February 2014 13:01, Andrew Dunstan and...@dunslane.net wrote:
On 02/28/2014 07:19 AM, Thom Brown wrote:
On 28 February 2014 08:12, Andres Freund and...@2ndquadrant.com mailto:
and...@2ndquadrant.com wrote:
On 2014-02-27 15:06:33 -0500, Andrew Dunstan wrote:
You realize
On 02/28/2014 07:19 AM, Thom Brown wrote:
On 28 February 2014 08:12, Andres Freund and...@2ndquadrant.com
mailto:and...@2ndquadrant.com wrote:
On 2014-02-27 15:06:33 -0500, Andrew Dunstan wrote:
You realize that this API dates from 9.3 and has been used in
numerous
* Peter Geoghegan (p...@heroku.com) wrote:
On Thu, Feb 27, 2014 at 8:07 PM, Peter Geoghegan p...@heroku.com wrote:
I'm not advocating authoring two extensions. I am tentatively
suggesting that we look at one extension for everything. That may well
be the least worst thing.
(Not that it's
On Thu, Feb 27, 2014 at 8:55 PM, Christophe Pettus x...@thebuild.com wrote:
On Feb 27, 2014, at 5:31 PM, Peter Geoghegan p...@heroku.com wrote:
Now, it's confusing that it has to go through hstore, perhaps, but
that's hardly all that bad in and of itself.
Yes, it is. It strikes me as
On 02/28/2014 09:27 AM, Robert Haas wrote:
On Thu, Feb 27, 2014 at 8:55 PM, Christophe Pettus x...@thebuild.com wrote:
On Feb 27, 2014, at 5:31 PM, Peter Geoghegan p...@heroku.com wrote:
Now, it's confusing that it has to go through hstore, perhaps, but
that's hardly all that bad in and of
* Robert Haas (robertmh...@gmail.com) wrote:
Taken individually, none of those decisions seem crazy, but taken
together it's pretty weird. Instead of inventing a new type (jsonb)
designed from the ground up to do what we want, we're, well, we're
doing what Christophe says: creating our own
101 - 200 of 431 matches
Mail list logo
