In what sense are we really stopping hstore development if hstore2
lives as jsonb? I have a hard time imagining someone dealing with the
incompatibility that a user-facing hstore2 would introduce, while
still preferring hstore syntax over json syntax given the choice.
There are very rich facilit
On Thu, Mar 6, 2014 at 12:23 AM, Teodor Sigaev wrote:
> That's possible to introduce GUC variable for i/o functions which will
> control old "bug-to-bug" behavior. IMHO, this is much better option that
> stopping hstore development or split hstore to two branches.
A GUC that controls i/o function
Thank you for checking that. Teodor's goal was that new-hstore be 100%
backwards-compatible with old-hstore. If we're breaking APIs, then it
That's true. Binary format is fully compatible unless old hstore value has more
than 2^28 key-value pairs (256 mln which is far from reachable by memor
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 o
On Wed, Mar 5, 2014 at 11:32 AM, Bruce Momjian 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 code mainten
On Wed, Mar 5, 2014 at 4:24 PM, Stephen Frost wrote:
> * Merlin Moncure (mmonc...@gmail.com) wrote:
>> On Wed, Mar 5, 2014 at 2:46 PM, Stephen Frost 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
>>
* Merlin Moncure (mmonc...@gmail.com) wrote:
> On Wed, Mar 5, 2014 at 2:46 PM, Stephen Frost 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 changed because
On Wed, Mar 5, 2014 at 2:45 PM, Alvaro Herrera 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 your users do not
>>
Merlin Moncure escribió:
> On Wed, Mar 5, 2014 at 11:44 AM, Stephen Frost 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 backwards-incompatible
* Merlin Moncure (mmonc...@gmail.com) wrote:
> On Wed, Mar 5, 2014 at 11:44 AM, Stephen Frost 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 bac
On Wed, Mar 5, 2014 at 11:44 AM, Stephen Frost wrote:
> * Merlin Moncure (mmonc...@gmail.com) wrote:
>> On Wed, Mar 5, 2014 at 10:43 AM, Stephen Frost 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 bi
On Wed, Mar 5, 2014 at 10:59:37AM -0800, Peter Geoghegan wrote:
> On Wed, Mar 5, 2014 at 8:30 AM, Robert Haas 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
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
On Wed, Mar 5, 2014 at 10:59:37AM -0800, Peter Geoghegan wrote:
> On Wed, Mar 5, 2014 at 8:30 AM, Robert Haas 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
On Wed, Mar 5, 2014 at 8:30 AM, Robert Haas 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?
>
>
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 yo
On Wed, Mar 5, 2014 at 11:19 AM, Tom Lane wrote:
> Merlin Moncure writes:
>> On Wed, Mar 5, 2014 at 10:24 AM, Tom Lane 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* ext
* Merlin Moncure (mmonc...@gmail.com) wrote:
> On Wed, Mar 5, 2014 at 10:43 AM, Stephen Frost 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 installed to us
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. I
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
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Mar 5, 2014 at 11:50 AM, Bruce Momjian 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 wit
On Wed, Mar 5, 2014 at 11:50 AM, Bruce Momjian 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 would it ta
Merlin Moncure writes:
> On Wed, Mar 5, 2014 at 10:24 AM, Tom Lane 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 included in the hstore extension
On Mar 5, 2014, at 8:49 AM, Andrew Dunstan 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 knocked out?
> In
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 spli
On Wed, Mar 5, 2014 at 10:43 AM, Stephen Frost wrote:
> * Merlin Moncure (mmonc...@gmail.com) wrote:
>> On Wed, Mar 5, 2014 at 10:24 AM, Tom Lane wrote:
>> > Merlin Moncure writes:
>> *All* non-sql standard types ought to be in extensions in an ideal
>> world.
>> >
>> > While there's
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 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 all
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, nob
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 d
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 instead
On Wed, Mar 5, 2014 at 11:16:01AM -0500, Tom Lane wrote:
> Bruce Momjian 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 automatica
* Merlin Moncure (mmonc...@gmail.com) wrote:
> On Wed, Mar 5, 2014 at 10:24 AM, Tom Lane wrote:
> > Merlin Moncure 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 exte
On Wed, Mar 5, 2014 at 10:24 AM, Tom Lane wrote:
> Merlin Moncure 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
* 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 11:24 AM, Tom Lane wrote:
> Merlin Moncure 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
On Wed, Mar 5, 2014 at 11:07 AM, Tom Lane wrote:
> Robert Haas 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 clearl
* 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 10:19 AM, Andres Freund 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 ones.
Certainly. Note
Merlin Moncure 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 be included in th
On 2014-03-05 10:10:23 -0600, Merlin Moncure wrote:
> On Wed, Mar 5, 2014 at 9:52 AM, Bruce Momjian 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 this but
Bruce Momjian 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 also modify pg_u
On Mon, Mar 3, 2014 at 11:20 PM, Peter Geoghegan wrote:
> On Mon, Mar 3, 2014 at 6:59 PM, Josh Berkus 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 collecti
On Wed, Mar 5, 2014 at 9:52 AM, Bruce Momjian 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 wrote:
>> > So, I am going to ask a back-track question and ask why we can't move
>> > hstore into core.
>>
>> This is exactly th
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 writes:
> >>On Wed, Mar 5, 2014 at 9:24 AM, Tom Lane wrote:
> >>>Also, there might be other cases besides arrays where we've embedded
> >>>type OIDs in on-disk data; anyo
Robert Haas 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 ended up with,
> and
On Wed, Mar 5, 2014 at 10:19 AM, Merlin Moncure wrote:
> On Wed, Mar 5, 2014 at 8: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.
>
> This is exactly the opposite of what should be happening. Now, jsonb
> might make it int
On Wed, Mar 5, 2014 at 09:19:33AM -0600, Merlin Moncure wrote:
> On Wed, Mar 5, 2014 at 8: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.
>
> This is exactly the opposite of what should be happening. Now, jsonb
> might
On 03/05/2014 10:30 AM, Tom Lane wrote:
Merlin Moncure writes:
On Wed, Mar 5, 2014 at 9: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?
composite types.
But that's only the composite type's own OID, no?
Merlin Moncure writes:
> On Wed, Mar 5, 2014 at 9: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?
> composite types.
But that's only the composite type's own OID, no? So it's not really
a problem unle
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 (pgsql-hackers@postg
On Wed, Mar 5, 2014 at 9:24 AM, Tom Lane wrote:
> Andrew Dunstan 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
Andrew Dunstan 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 be
>> fixed?
On Wed, Mar 5, 2014 at 8: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.
This is exactly the opposite of what should be happening. Now, jsonb
might make it into core because of the json precedent but the entire
purpose of th
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 problem,
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 f
On 03/03/2014 09:06 PM, Peter Geoghegan wrote:
> On Mon, Mar 3, 2014 at 9:05 PM, Andrew Dunstan 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
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 equal
On Tue, Mar 4, 2014 at 6:48 AM, Teodor Sigaev wrote:
>> On Tue, Mar 4, 2014 at 2:44 AM, Teodor Sigaev 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
On Tue, Mar 4, 2014 at 2:44 AM, Teodor Sigaev 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 trim and
doesn't de
On Tue, Mar 4, 2014 at 2:44 AM, Teodor Sigaev 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 reported, because th
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 t
I tried try.mongodb.com
> 25 == 25.0
true
On Tue, Mar 4, 2014 at 2:18 PM, Peter Geoghegan wrote:
> On Tue, Mar 4, 2014 at 2:18 AM, Teodor Sigaev wrote:
>> That is because compareJsonbValue compares numeric values with a help of
>> numeric_cmp() instead of comparing text representation. This inc
On Tue, Mar 4, 2014 at 2:18 AM, Peter Geoghegan wrote:
> On Tue, Mar 4, 2014 at 2:18 AM, Teodor Sigaev 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.
Perha
On Tue, Mar 4, 2014 at 2:07 AM, Teodor Sigaev 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
> type) you n
On Tue, Mar 4, 2014 at 2:18 AM, Teodor Sigaev 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 mailing list (pgsql
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
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 JavaScr
On Tue, Mar 4, 2014 at 1:30 AM, Oleg Bartunov 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
+ OPERATOR7 @>
Thanks, looks like a bug.
On Tue, Mar 4, 2014 at 12:38 PM, Peter Geoghegan wrote:
> Hi Oleg,
>
> On Mon, Mar 3, 2014 at 7:17 AM, Oleg Bartunov wrote:
>> you can always look at our development repository:
>
> I think I found a bug:
>
> [local]/postgres=# \d+ bar
> Table "
Hi Oleg,
On Mon, Mar 3, 2014 at 7:17 AM, Oleg Bartunov 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
+---+-
On Mon, Mar 3, 2014 at 8:59 PM, Andrew Dunstan 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 did as mu
On Mon, Mar 3, 2014 at 9:05 PM, Andrew Dunstan 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
--
Sent via pgsql-hack
On 03/03/2014 11:20 PM, Peter Geoghegan wrote:
On Mon, Mar 3, 2014 at 6:59 PM, Josh Berkus 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
On 03/03/2014 10:39 PM, Peter Geoghegan wrote:
On Mon, Mar 3, 2014 at 6:54 PM, Andrew Dunstan 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 s
On Mon, Mar 3, 2014 at 6:59 PM, Josh Berkus 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 course, we need a
On Mon, Mar 3, 2014 at 7:39 PM, Peter Geoghegan 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 that. I
On Mon, Mar 3, 2014 at 6:54 PM, Andrew Dunstan 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 json because it l
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 03/03/2014 07:50 PM, Peter Geoghegan wrote:
On Fri, Feb 28, 2014 at 2:12 PM, Peter Geoghegan 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 p
On Mon, Mar 3, 2014 at 5:09 PM, Josh Berkus 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
>> into
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 4:57 PM, Josh Berkus 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 hstore operator
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 thes
On Fri, Feb 28, 2014 at 2:12 PM, Peter Geoghegan 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 indexing (the hstor
On 04/03/14 04:25, Oleg Bartunov wrote:
On Mon, Mar 3, 2014 at 7:22 PM, Andres Freund 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 particularly careless, y
On Mon, Mar 3, 2014 at 7:22 PM, Andres Freund 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.
>
> I'll try to hav
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 we
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 patch
On 2014-03-03 08:57:59 -0600, Merlin Moncure wrote:
> On Fri, Feb 28, 2014 at 2:01 PM, Andres Freund 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 cro
On Fri, Feb 28, 2014 at 2:01 PM, Andres Freund 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 don't think
> i
On Fri, Feb 28, 2014 at 2:40 PM, Christophe Pettus wrote:
> On Feb 28, 2014, at 2:12 PM, Peter Geoghegan wrote:
>
>> AFAICT, we have these
>> operator classes that work fine with jsonb for the purposes of
>> hstore-style indexing (the hstore operator classes).
>
> That assumes that it is acceptab
On Feb 28, 2014, at 2:12 PM, Peter Geoghegan wrote:
> AFAICT, we have these
> operator classes that work fine with jsonb for the purposes of
> hstore-style indexing (the hstore operator classes).
That assumes that it is acceptable that jsonb be packaged in the hstore
extension. To put it mild
On Fri, Feb 28, 2014 at 1:38 PM, Christophe Pettus wrote:
> jsonb is significantly faster than json even without indexing; there are
> plenty of reasons to have jsonb even if we don't initially have indexing
> operations for it.
That may be true, although I think that that's still very disappoi
On Feb 28, 2014, at 1:34 PM, Peter Geoghegan wrote:
> Amazon RDS Postgres has hstore.
Just observing that putting something in -contrib does not mean every
installation can automatically adopt it.
--
-- Christophe Pettus
x...@thebuild.com
--
Sent via pgsql-hackers mailing list (pgsql-h
On Feb 28, 2014, at 1:35 PM, Peter Geoghegan wrote:
> I don't think hstore-style indexing is "advanced"; it's the main
> reason for there being a jsonb, in my view.
jsonb is significantly faster than json even without indexing; there are plenty
of reasons to have jsonb even if we don't initiall
On Fri, Feb 28, 2014 at 1:25 PM, Andrew Dunstan wrote:
> The only "dependency" is if you want to be able to use some advanced
> indexing and other functionality, for which we don't currently have jsonb
> equivalents of the new hstore operators, because we ran out of time. Then
> you can get this f
On Fri, Feb 28, 2014 at 1:31 PM, Christophe Pettus wrote:
> I'll also mention that an increasingly large number of people are running
> PostgreSQL in an environment where they don't get to pick what packages are
> installed on their server (RDS, for example). Telling them that something is
> i
On Feb 28, 2014, at 1:03 PM, Josh Berkus wrote:
> However, the problems with admins not wanting to install -contrib aren't
> really about what's in or not in -contrib.
I'll also mention that an increasingly large number of people are running
PostgreSQL in an environment where they don't get to
On 02/28/2014 03:19 PM, Tom Lane wrote:
Andrew Dunstan writes:
That hasn't been the way we've done things in the past. We're frequently
incremental. New features sometimes take several releases to mature.
That's perfectly fair. What I don't want to see is a user-visible
dependency from jsonb
On 02/28/2014 11:19 AM, Greg Stark wrote:
> On Fri, Feb 28, 2014 at 7:12 PM, Josh Berkus wrote:
>> * As cited, many sysadmins block the install of the -contrib package.
>
> Of course the more you put things in core the more you make this logic
> sound reasonable.
Touche'!
However, the problems
101 - 200 of 431 matches
Mail list logo
