Re: [HACKERS] jsonb and nested hstore
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 facilities for manipulating json available in every programming language. The same is not true of hstore. It's true for perl. Syntax of hstore is close to hash/array syntax and it's easy serialize/deserialize hstore to/from perl. Syntax of hstore was inspired by perl. -- 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 to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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 functions is generally considered to be an unacceptable hack. 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 facilities for manipulating json available in every programming language. The same is not true of hstore. Having looked at the issue today, I think that the amount of redundant code between a hstore2 in core as jsonb and hstore1 will be acceptable. The advantages of making a clean-break in having to support the legacy hstore disk format strengthen the case for doing so too. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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 memory requirements). The single issue is a GiST index, GIN index should be recreated to utilize new features. doesn't really work to force users to upgrade the type, no? Teodor, are these output changes things that can be made consistent, or do we need separate hstore and hstore2 datatypes? Introducing types in hstore causes this incompatibility - but I don't think that's huge or even big problem. In most cases application does quoting (sets "1" instead of just 1) to preserve SQL-injection and to protect hstore-forbidden characters in hstore. Keys leaves untouched - it could be only a string. 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. -- 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 to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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 the lines of the patch > submitted are due to changes in the output format of hstore, and the > need to update the hstore tests' expected results to reflect these > changes. For example: 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 doesn't really work to force users to upgrade the type, no? Teodor, are these output changes things that can be made consistent, or do we need separate hstore and hstore2 datatypes? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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 maintenance perspective, I like that the > non-hierarchical hstore code is not going in core. Yeah. 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 the lines of the patch submitted are due to changes in the output format of hstore, and the need to update the hstore tests' expected results to reflect these changes. For example: *** select slice(hstore 'aa=>1, b=>2, c=>3', *** 759,779 (1 row) select slice(hstore 'aa=>1, b=>2, c=>3', ARRAY['c','b']); !slice ! ! "b"=>"2", "c"=>"3" (1 row) select slice(hstore 'aa=>1, b=>2, c=>3', ARRAY['aa','b']); ! slice ! - ! "b"=>"2", "aa"=>"1" (1 row) select slice(hstore 'aa=>1, b=>2, c=>3', ARRAY['c','b','aa']); ! slice ! --- ! "b"=>"2", "c"=>"3", "aa"=>"1" (1 row) select pg_column_size(slice(hstore 'aa=>1, b=>2, c=>3', ARRAY['c','b'])) --- 777,797 (1 row) select slice(hstore 'aa=>1, b=>2, c=>3', ARRAY['c','b']); ! slice ! ! "b"=>2, "c"=>3 (1 row) select slice(hstore 'aa=>1, b=>2, c=>3', ARRAY['aa','b']); ! slice ! - ! "b"=>2, "aa"=>1 (1 row) select slice(hstore 'aa=>1, b=>2, c=>3', ARRAY['c','b','aa']); ! slice ! - ! "b"=>2, "c"=>3, "aa"=>1 (1 row) I could believe that there was at least something to be said for a user-visible hstore2 if the new capabilites were available without breaking application code, but it seems that isn't the case. Anyone who is going to have to deal with some of this kind of incompatibility one way or the other might as well switch over to jsonb entirely. When changing aspects of our output format like this, the impact on users is more or less a step function (of the number of small changes). -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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 >> extension'). Functions can't be removed or changed because of legacy >> application support. In an extension world, they can -- albeit not >> 'magically', but at least it can be done. > > That simply isn't accurate on either level- if there is concern about > application support, that can apply equally to core and contrib, and we > certainly *can* remove and/or redefine functions in core with sufficient > cause. It's just not something we do lightly for things living in > either core or contrib. > > For an example, consider the FDW API, particularly what we did between > 9.1 and 9.2. Well, we'll have to agree to disagree I suppose. Getting back on topic, the question is 'what about jsonb/hstore2'? At this point my interests are practical. I promised (heh) to bone up the docs. I'm on vacation this weekend so it's looking like around sometime late next week for that. In particular, it'd be helpful to get some kind of read on the final disposition of hstore2. merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
* 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 of legacy > application support. In an extension world, they can -- albeit not > 'magically', but at least it can be done. That simply isn't accurate on either level- if there is concern about application support, that can apply equally to core and contrib, and we certainly *can* remove and/or redefine functions in core with sufficient cause. It's just not something we do lightly for things living in either core or contrib. For an example, consider the FDW API, particularly what we did between 9.1 and 9.2. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] jsonb and nested hstore
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
>> have to adjust all the code you would have broken. Perhaps for
>> in-core extensions you offer the old one in contrib for a while until
>> a reasonable amount of time passes then move it out to pgxn.
>
> Uhm. Would it work to define a new version of foo, say 2.0, but keep
> the old 1.2 version the default? That way, if you want to keep the old
> foo you do nothing (after both fresh install and pg_upgrade), and if you
> want to upgrade to the new code, it's just an ALTER EXTENSION UPDATE
> away.
Certainly. The important point though is that neither option is
available if the old stuff is locked into the public namespace.
Consider various warts like the array ('array_upper' et al) API or geo
types. We're stuck with them. Even with jsonb: it may be the hot new
thing *today* but 5 years down the line there's json2 that does all
kinds of wonderful things we haven't thought about -- what if it
displaces current usages? The very same people who are arguing that
jsonb should not be in an extension are the ones arguing json is
legacy and to be superseded. These two points of view IMO are
directly in conflict: if json would have been an extension than the
path to deprecation is clear. Now the json functions are in the
public namespace. Forever (or at least for a very long time).
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 of legacy
application support. In an extension world, they can -- albeit not
'magically', but at least it can be done.
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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 > > way then you're going to cause a lot of grief for people. > > 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 > have to adjust all the code you would have broken. Perhaps for > in-core extensions you offer the old one in contrib for a while until > a reasonable amount of time passes then move it out to pgxn. Uhm. Would it work to define a new version of foo, say 2.0, but keep the old 1.2 version the default? That way, if you want to keep the old foo you do nothing (after both fresh install and pg_upgrade), and if you want to upgrade to the new code, it's just an ALTER EXTENSION UPDATE away. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
* 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 backwards-incompatible > > way then you're going to cause a lot of grief for people. > > 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 > have to adjust all the code you would have broken. Perhaps for > in-core extensions you offer the old one in contrib for a while until > a reasonable amount of time passes then move it out to pgxn. This is > a vastly better system than the choices we have now, which is A. break > code or B. do nothing. I don't see why we can't do exactly what you're suggesting in core. This whole thread is about doing exactly that, in fact, which is why we're talking about 'jsonb' instead of just 'json'. I agree that we don't push too hard to remove things from core, but it's not like we've had a whole ton of success kicking things out of -contrib either. > > I *really* hate how extensions end up getting dumped into the "public" > > schema and I'm not a big fan for having huge search_paths either. > > At least with extensions you have control over this. Yeah, but I much prefer how things end up in pg_catalog rather than public or individual schemas. > > mentioned earlier- I'm also not advocating that everything be put into > > core. I don't follow what you mean by "Internal C libraries don't have > > to be supported" because, > > I mean, we are free to change them or delete them. They do not come > with the legacy that user facing API comes. They also do not bloat > the public namespace. But we actually *aren't* free to change or delete them- which is what I was getting at. Certainly, in back-branches we regularly worry about breaking things for users of C functions, and there is some consideration for them even in major version changes. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] jsonb and nested hstore
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 bits end up in an >> > extension that has to be installed to use what would have to already be >> > there. I don't see that as any kind of improvement. >> >> If you don't then you simply have not been paying attention to the >> endless backwards compatibility problems we've faced which are highly >> ameliorated in an extension heavy world. > > 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 > way then you're going to cause a lot of grief for people. 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 have to adjust all the code you would have broken. Perhaps for in-core extensions you offer the old one in contrib for a while until a reasonable amount of time passes then move it out to pgxn. This is a vastly better system than the choices we have now, which is A. break code or B. do nothing. >> Also, you're ignoring the >> fact that having an endlessly accreting set of symbols in the public >> namespace is not free. Internal C libraries don't have to be >> supported and don't have any signficant user facing costs by simply >> being there. > > I *really* hate how extensions end up getting dumped into the "public" > schema and I'm not a big fan for having huge search_paths either. At least with extensions you have control over this. > mentioned earlier- I'm also not advocating that everything be put into > core. I don't follow what you mean by "Internal C libraries don't have > to be supported" because, I mean, we are free to change them or delete them. They do not come with the legacy that user facing API comes. They also do not bloat the public namespace. merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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 someone were to decide to do the > >> work instead of argue about it? > > > > I believe the main thing is the opclasses. > > Yes, that's right. A large volume of code currently proposed for > hstore2 is much less valuable than those operators sufficient to > implement the hstore2 opclasses. If you assume that hstore will become > a legacy extension that we won't add anything to (including everything > proposed in any patch posted to this thread), and jsonb will go in > core (which is of course more or less just hstore2 with a few json > extras), the amount of code redundantly shared between core and an > unchanged hstore turns out to not be that bad. I hope to have a > precise answer to just how bad soon. 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 maintenance perspective, I like that the non-hierarchical hstore code is not going in core. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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 json users, the hstore users are going to get an automatic upgrade whether they want it or not. Mind you, I can't see a reason NOT to want it ... -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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 someone were to decide to do the > >> work instead of argue about it? > > > > I believe the main thing is the opclasses. > > Yes, that's right. A large volume of code currently proposed for > hstore2 is much less valuable than those operators sufficient to > implement the hstore2 opclasses. If you assume that hstore will become > a legacy extension that we won't add anything to (including everything > proposed in any patch posted to this thread), and jsonb will go in > core (which is of course more or less just hstore2 with a few json > extras), the amount of code redundantly shared between core and an > unchanged hstore turns out to not be that bad. I hope to have a > precise answer to just how bad soon. Can you clarify what hstore2 is? It that the name of a type? Is that hierarchical hstore with the same hstore name? -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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? > > I believe the main thing is the opclasses. Yes, that's right. A large volume of code currently proposed for hstore2 is much less valuable than those operators sufficient to implement the hstore2 opclasses. If you assume that hstore will become a legacy extension that we won't add anything to (including everything proposed in any patch posted to this thread), and jsonb will go in core (which is of course more or less just hstore2 with a few json extras), the amount of code redundantly shared between core and an unchanged hstore turns out to not be that bad. I hope to have a precise answer to just how bad soon. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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 change or remove later. > That seems like an approach possibly worth investigating. It's not > too different from what we did when we moved text search into core. > The basic idea seems to be that we want jsonb in core, and we expect > it to replace hstore, but we can't get just get rid of hstore because > it has too many users Yes, please! This was the original approach that we talked about and everyone agreed to, and what Andrew has been trying to implement. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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* extension; it'd have to be included in the hstore extension. > >> I disagree with that. The shared C bits can live inside the core >> system and the SQL level hooks and extension specific behaviors could >> live in an extension. > > That approach abandons every bit of value in an extension, no? > You certainly don't get to fix bugs outside a core-system release cycle. That's core vs non core debate. Just about everyone (including me) wants json and hstore to live in core -- meaning packaged, shipped, supported, and documented with the postgresql source code releases. Only an elite set of broadly useful and popular extensions get that honor of which json is most certainly one. Moreover, you give up nothing except the debate/approval issues to get your code in core. If you want to release off cycle, you can certainly do that and enterprising users can simply install the extension manually (or perhaps via pgxn) instead of via contrib. BTW,This is yet another thing that becomes impossible if you don't extension (on top of legacy/backwards compatibility issues and general bloat which is IMNSHO already a pretty severe situation). merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
* 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 use what would have to already be > > there. I don't see that as any kind of improvement. > > If you don't then you simply have not been paying attention to the > endless backwards compatibility problems we've faced which are highly > ameliorated in an extension heavy world. 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 way then you're going to cause a lot of grief for people. Doing that to everyone who uses hstore, just because it's an extension, doesn't make it acceptable. On this thread we're already argueing about exactly that issue and how to avoid breaking things for those users were we to move hstore into core. > Also, you're ignoring the > fact that having an endlessly accreting set of symbols in the public > namespace is not free. Internal C libraries don't have to be > supported and don't have any signficant user facing costs by simply > being there. I *really* hate how extensions end up getting dumped into the "public" schema and I'm not a big fan for having huge search_paths either. As I mentioned earlier- I'm also not advocating that everything be put into core. I don't follow what you mean by "Internal C libraries don't have to be supported" because, clearly, anything released would have to be supported and if the extension is calling into a C interface then we'd have to support that interface for that extension *and anyone else who uses it*. We don't get to say "oh, this C function can only be used by extensions we bless." We already worry less about breaking backwards compatibility for C-level functions across PG major versions, but that's true for both in-core hooks and extensions. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] jsonb and nested hstore
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 am suggesting that core/contrib split problems are not symptomatic of data type problems, and if address/address the core/contrib split issue, the data type might be just fine. Splitting out jsonb to an extension is going to be moderately painful. The json and jsonb functions share some code that's not exposed (and probably shouldn't be). It's not likely to be less painful than implementing the hstore GIN/GIST ops for jsonb, I suspect the reverse. OK, that's good information. So we have JSONB which ties to a core type, JSON, _and_ to a contrib module, hstore. No wonder it is so complex. Well, "ties to" is a loose term. It's hstore in these patches that depends on jsonb - necessarily since we can't have core code depend on an extension. I am warming up to the idea of moving hstore internals into core, sharing that with JSONB, and having contrib/hstore just call the core functions when defining its data type. Right, at least the parts they need in common. That's how I'd handle the GIN/GIST ops, for example. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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 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 change or remove later. > > That seems like an approach possibly worth investigating. It's not > too different from what we did when we moved text search into core. > The basic idea seems to be that we want jsonb in core, and we expect > it to replace hstore, but we can't get just get rid of hstore because > it has too many users. Yes. It eliminates the problem of code duplication, but keeps hstore in contrib for flexibility and compatibility. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
* 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 with JSONB, but hstore remains > > as an extension that you can change or remove later. > > That seems like an approach possibly worth investigating. It's not > too different from what we did when we moved text search into core. > The basic idea seems to be that we want jsonb in core, and we expect > it to replace hstore, but we can't get just get rid of hstore because > it has too many users. This might be valuable for hstore, specifically, because we can't easily move it into core. I'm fine with that- the disagreement I have is with the more general idea that everything not-defined-by-committee should be in shim extensions which just provide basically the catalog entries for types which are otherwise all in core. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] jsonb and nested hstore
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 take to >> > copy-and-paste all that code, if someone were to decide to do the >> > work instead of argue about it? >> >> Somewhere upthread, Peter seemed to estimate it at a day, if I >> understood correctly. If that's accurate, I'm certainly behind getting >> it done and in and moving on. I'm sure no one particularly likes a >> bunch of copy/pasteing of code, but if it would get us to the point of >> having a really working jsonb that everyone is happy with, I'm all for >> it. >> >> 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 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 change or remove later. That seems like an approach possibly worth investigating. It's not too different from what we did when we moved text search into core. The basic idea seems to be that we want jsonb in core, and we expect it to replace hstore, but we can't get just get rid of hstore because it has too many users. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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. > I disagree with that. The shared C bits can live inside the core > system and the SQL level hooks and extension specific behaviors could > live in an extension. That approach abandons every bit of value in an extension, no? You certainly don't get to fix bugs outside a core-system release cycle. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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? > Incidentally, this would probably have been done quite weeks ago if people > had not objected to my doing any more on the feature. Of course missing the > GIN/GIST ops was not part of the design. Quite the contrary. That was my understanding, as well. Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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 problems are not symptomatic of data type problems, > >and if address/address the core/contrib split issue, the data type might > >be just fine. > > > > > Splitting out jsonb to an extension is going to be moderately > painful. The json and jsonb functions share some code that's not > exposed (and probably shouldn't be). It's not likely to be less > painful than implementing the hstore GIN/GIST ops for jsonb, I > suspect the reverse. OK, that's good information. So we have JSONB which ties to a core type, JSON, _and_ to a contrib module, hstore. No wonder it is so complex. I am warming up to the idea of moving hstore internals into core, sharing that with JSONB, and having contrib/hstore just call the core functions when defining its data type. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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 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. >> >> I disagree with that. The shared C bits can live inside the core >> system and the SQL level hooks and extension specific behaviors could >> live in an extension. AFAICT moving jsonb to extension is mostly a >> function of migrating the hard coded SQL hooks out to an extension >> (I'm probably oversimplifying though). > > 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 use what would have to already be > there. I don't see that as any kind of improvement. If you don't then you simply have not been paying attention to the endless backwards compatibility problems we've faced which are highly ameliorated in an extension heavy world. Also, you're ignoring the fact that having an endlessly accreting set of symbols in the public namespace is not free. Internal C libraries don't have to be supported and don't have any signficant user facing costs by simply being there. merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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 allow user hstore columns to automatically map to the new constant hstore oid. We can also modify pg_upgrade to scan all the user tables for any use of hstore arrays and perhaps composite types and tell the user they have to drop and upgrade those table separately. Yeah, and that doesn't seem terribly acceptable. Unless you think the field usage of hstore[] is nil; which maybe it is, I'm not sure what the usage patterns are like. In general it would not be acceptable at all to not be able to support migrations of array columns. It would prevent migration of _hstore_ array columns, which might be acceptable. If we say pg_upgrade can never decline an upgrade, we basically limit changes and increase the odds of needing a total pg_upgrade-breaking release someday to re-adjust everything. I basically think that a split between contrib and core for the internally same data type just isn't sustainable. Another conern is that it doesn't seem we are sure if we want JSONB in core or contrib, at least based on some comments, so we should probably decide that now, as I don't think the decision is going to be any easier in the future. And as discussed above, moving something from contrib to core has its own complexities. 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 problems are not symptomatic of data type problems, and if address/address the core/contrib split issue, the data type might be just fine. Splitting out jsonb to an extension is going to be moderately painful. The json and jsonb functions share some code that's not exposed (and probably shouldn't be). It's not likely to be less painful than implementing the hstore GIN/GIST ops for jsonb, I suspect the reverse. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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, nobody's been able to provide a pointer to any > previous discussion of the points under debate. That's because the > points that are *actually* being debated here were not discussed > previously. I recognize that Josh and Andrew would like to make that > the fault of the people who are now raising objections, but it doesn't > work like that. The fact that people were and are *generally* in > favor of jsonb and hstore doesn't mean they have to like the way that > the patches have turned out. I am assuming much of this was discussed verbally, and many of us were not present. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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 to do the > > work instead of argue about it? > > Somewhere upthread, Peter seemed to estimate it at a day, if I > understood correctly. If that's accurate, I'm certainly behind getting > it done and in and moving on. I'm sure no one particularly likes a > bunch of copy/pasteing of code, but if it would get us to the point of > having a really working jsonb that everyone is happy with, I'm all for > it. > > 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 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 change or remove later. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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 of argue about it? Somewhere upthread, Peter seemed to estimate it at a day, if I understood correctly. If that's accurate, I'm certainly behind getting it done and in and moving on. I'm sure no one particularly likes a bunch of copy/pasteing of code, but if it would get us to the point of having a really working jsonb that everyone is happy with, I'm all for it. 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? 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. Incidentally, this would probably have been done quite weeks ago if people had not objected to my doing any more on the feature. Of course missing the GIN/GIST ops was not part of the design. Quite the contrary. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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 automatically map > > to the new constant hstore oid. We can also modify pg_upgrade to scan > > all the user tables for any use of hstore arrays and perhaps composite > > types and tell the user they have to drop and upgrade those table > > separately. > > Yeah, and that doesn't seem terribly acceptable. Unless you think the > field usage of hstore[] is nil; which maybe it is, I'm not sure what > the usage patterns are like. In general it would not be acceptable > at all to not be able to support migrations of array columns. It would prevent migration of _hstore_ array columns, which might be acceptable. If we say pg_upgrade can never decline an upgrade, we basically limit changes and increase the odds of needing a total pg_upgrade-breaking release someday to re-adjust everything. I basically think that a split between contrib and core for the internally same data type just isn't sustainable. Another conern is that it doesn't seem we are sure if we want JSONB in core or contrib, at least based on some comments, so we should probably decide that now, as I don't think the decision is going to be any easier in the future. And as discussed above, moving something from contrib to core has its own complexities. 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 problems are not symptomatic of data type problems, and if address/address the core/contrib split issue, the data type might be just fine. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
* 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 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. > > I disagree with that. The shared C bits can live inside the core > system and the SQL level hooks and extension specific behaviors could > live in an extension. AFAICT moving jsonb to extension is mostly a > function of migrating the hard coded SQL hooks out to an extension > (I'm probably oversimplifying though). 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 use what would have to already be there. I don't see that as any kind of improvement. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] jsonb and nested hstore
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 as a > *separate* extension; it'd have to be included in the hstore extension. I disagree with that. The shared C bits can live inside the core system and the SQL level hooks and extension specific behaviors could live in an extension. AFAICT moving jsonb to extension is mostly a function of migrating the hard coded SQL hooks out to an extension (I'm probably oversimplifying though). > 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? Basically opclasses, operators (particularly search operators) and functions/operators to manipulate the hstore in place. Personally I'm not inclined to copy/paste the code. I'd also like to see this stuff committed, and don't want to hold up the patch for that unless it's determined for other reasons (and by other people) this is the only reasonable path for 9.4. merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
* 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, Peter seemed to estimate it at a day, if I understood correctly. If that's accurate, I'm certainly behind getting it done and in and moving on. I'm sure no one particularly likes a bunch of copy/pasteing of code, but if it would get us to the point of having a really working jsonb that everyone is happy with, I'm all for it. 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? Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] jsonb and nested hstore
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 as a > *separate* extension; it'd have to be included in the hstore extension. > Which is weird, and quite a mixed message from the marketing standpoint. > If I understand Josh's vision of the future, he's expecting that hstore > will gradually die off in favor of jsonb, so we don't really want to > present the latter as the ugly stepchild. > > 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? I believe the main thing is the opclasses. My information might be incomplete. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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 clearly laying out the design that we've ended up with, >> and I'm willing to wager any reasonable amount of money that if >> someone had posted an email saying "hey, we're thinking about setting >> things up so that jsonb and hstore have the same binary format, but >> you can't index jsonb directly, you have to cast it to hstore, is >> everyone OK with that?" someone would have written back and said "no, >> that sounds nuts". The reason why input on that particular aspect of >> the design was not forthcoming isn't because everyone was OK with it; >> it's because it was never clearly spelled out. > > No, that was never the design (I trust). It's where we are today > because time ran out to complete jsonb for 9.4, and tossing the index > opclasses overboard was one of the last-minute compromises in order > to have something submittable. Well, what I was told when I started objecting to the current state of affairs is that it was too late to "change course" now, which seemed to me to imply that this was the idea all along. On the other hand, Josh also said that there was a plan in the works to ship the missing opclasses on PGXN before 9.4 hits shelves, which is more along the lines of what you're saying. So, hey, I don't know. > I think it would be a completely defensible decision to postpone jsonb > to 9.5 on the grounds that it's not done enough. Now, Josh has laid out > arguments why we want jsonb in 9.4 even if it's incomplete. But ISTM > that those are fundamentally marketing arguments; on a purely technical > basis I think the decision would be to postpone. So it comes down > to how you weight marketing vs technical issues, which is something > that everyone is likely to see a little bit differently :-( I don't have any problem shipping incremental progress on important features, but once we ship things that are visible at the SQL level they get awfully hard to change, and my confidence that we won't want to change this is not very high right now. To the extent that we have a jsonb that is missing some features we will eventually want to have, I don't care; that's incremental development at its finest. To the extent that we have a jsonb that makes choices about what to store on disk or expose at the SQL level that we may regret later, that's not incremental development; that's just not being done. Anyone who thinks that digging ourselves out of a backward-compatibility hole will be painless enough to justify the marketing value of the feature has most probably not had to do it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
* 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 everything into core, but I agreed with having json in core and further feel jsonb should be there also. I'm not against having hstore either- and I *wish* we'd put ip4r in and replace our existing inet types with it. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] jsonb and nested hstore
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 I never said that the internal .so can't be in core that both extensions interface with and perhaps wrap. It would be nice to have a intra-extension call system worked out but that in no way plays to the bigger issues at stake. This is all about management of the public API; take a good skeptical look at the history of types like xml, json, geo, money and others. merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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 the hstore extension. Which is weird, and quite a mixed message from the marketing standpoint. If I understand Josh's vision of the future, he's expecting that hstore will gradually die off in favor of jsonb, so we don't really want to present the latter as the ugly stepchild. 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? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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 there have been enough > > counter-arguments that I am not ready to head in that direction. > > The only counter argument given is that this will prevent people from > being able to use extensions because they A: can't or won't install > contrib packages or B: are too stupid or lazy to type 'create > extension json'. Note I'm discussing 'in core extension vs in core > built in'. 'out of core extension' loosely translates to 'can't be > used by the vast majority of systems. 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. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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_upgrade to scan > all the user tables for any use of hstore arrays and perhaps composite > types and tell the user they have to drop and upgrade those table > separately. Yeah, and that doesn't seem terribly acceptable. Unless you think the field usage of hstore[] is nil; which maybe it is, I'm not sure what the usage patterns are like. In general it would not be acceptable at all to not be able to support migrations of array columns. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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 collective decision. So if we're going >> to change course, we need a specific reason to change course, not just >> "it seems like a better idea now" or "I wasn't paying attention then". > > I'm pretty sure it doesn't work like that. But if it does, what > exactly am I insisting on that is inconsistent with that consensus? In > what way are we changing course? I think I'm being eminently flexible. > I don't want a jsonb type that is broken, as for example by not having > a default B-Tree operator class. Why don't you let me get on with it? 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, nobody's been able to provide a pointer to any previous discussion of the points under debate. That's because the points that are *actually* being debated here were not discussed previously. I recognize that Josh and Andrew would like to make that the fault of the people who are now raising objections, but it doesn't work like that. The fact that people were and are *generally* in favor of jsonb and hstore doesn't mean they have to like the way that the patches have turned out. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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 the opposite of what should be happening. Now, jsonb >> might make it into core because of the json precedent but the entire >> purpose of the extension system is stop dumping everything in the >> public namespace. Stuff 'in core' becomes locked in stone, forever, >> because of backwards compatibility concerns, which are IMNSHO, a >> bigger set of issues than even pg_upgrade related issues. Have we >> gone through all the new hstore functions and made sure they don't >> break existing applications? Putting things in core welds your only >> escape hatch shut. >> >> *All* non-sql standard types ought to be in extensions in an ideal world. > > I have seen your opinion on this but there have been enough > counter-arguments that I am not ready to head in that direction. The only counter argument given is that this will prevent people from being able to use extensions because they A: can't or won't install contrib packages or B: are too stupid or lazy to type 'create extension json'. Note I'm discussing 'in core extension vs in core built in'. 'out of core extension' loosely translates to 'can't be used by the vast majority of systems. Most corporate IT departments (including mine) have a policy of only installing packages through the operating system packaging to simplify management of deploying updates. Really strict companies might not even allow anything but packages supplied by a vendor like redhat (which in practice keeps you some versions back from the latest). Now, if some crappy hosting company blocks contrib I don't believe at all that this should drive our project management decisions. Postgresql is both a database and increasingly a development language platform. Most good stacks have a system (cpan, npm, etgc) to manage the scope of the installed runtime and it's a routine and expected exercise to leverage that system. merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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; anyone remember? > >>composite types. > >But that's only the composite type's own OID, no? So it's not really > >a problem unless the type we wanted to move into (or out of) core was > >itself composite. > > > > > > > Sure, although that's not entirely impossible to imagine. I admit it > seems less likely, and I could accept it as a restriction if we > conquered the general case. OK, so let's look at the general case. Here is what pg_upgrade preserves: * We control all assignments of pg_class.oid (and relfilenode) so toast * oids are the same between old and new clusters. This is important * because toast oids are stored as toast pointers in user tables. * * While pg_class.oid and pg_class.relfilenode are initially the same * in a cluster, they can diverge due to CLUSTER, REINDEX, or VACUUM * FULL. In the new cluster, pg_class.oid and pg_class.relfilenode will * be the same and will match the old pg_class.oid value. Because of * this, old/new pg_class.relfilenode values will not match if CLUSTER, * REINDEX, or VACUUM FULL have been performed in the old cluster. * * We control all assignments of pg_type.oid because these oids are stored * in user composite type values. * * We control all assignments of pg_enum.oid because these oids are stored * in user tables as enum values. * * We control all assignments of pg_authid.oid because these oids are stored * in pg_largeobject_metadata. 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_upgrade to scan all the user tables for any use of hstore arrays and perhaps composite types and tell the user they have to drop and upgrade those table separately. Again, I am not asking what can be done for 9.4 but what is our final goal, though the pg_upgrade change are minimal as we have done such adjustments in the past. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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 I'm willing to wager any reasonable amount of money that if > someone had posted an email saying "hey, we're thinking about setting > things up so that jsonb and hstore have the same binary format, but > you can't index jsonb directly, you have to cast it to hstore, is > everyone OK with that?" someone would have written back and said "no, > that sounds nuts". The reason why input on that particular aspect of > the design was not forthcoming isn't because everyone was OK with it; > it's because it was never clearly spelled out. No, that was never the design (I trust). It's where we are today because time ran out to complete jsonb for 9.4, and tossing the index opclasses overboard was one of the last-minute compromises in order to have something submittable. I think it would be a completely defensible decision to postpone jsonb to 9.5 on the grounds that it's not done enough. Now, Josh has laid out arguments why we want jsonb in 9.4 even if it's incomplete. But ISTM that those are fundamentally marketing arguments; on a purely technical basis I think the decision would be to postpone. So it comes down to how you weight marketing vs technical issues, which is something that everyone is likely to see a little bit differently :-( regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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 into core because of the json precedent but the entire > purpose of the extension system is stop dumping everything in the > public namespace. Stuff 'in core' becomes locked in stone, forever, > because of backwards compatibility concerns, which are IMNSHO, a > bigger set of issues than even pg_upgrade related issues. Have we > gone through all the new hstore functions and made sure they don't > break existing applications? Putting things in core welds your only > escape hatch shut. I agree. What concerns me about jsonb is that it doesn't seem very done. If we commit it to core and find out later that we've made some mistakes we'd like to fix, it's going to be difficult and controversial. If it goes on PGXN and turns out to have some problems, then the people responsible for that extension can decide whether and how to preserve backward compatibility, or somebody else can write something completely different. On a theoretical level, I'd absolutely rather have jsonb in core - not because it's in any way theoretically necessary, but because JSON is popular and better support for it will be good for PostgreSQL. But on a practical level I'd rather not ship it in 9.4 than ship something we might later regret. 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 I'm willing to wager any reasonable amount of money that if someone had posted an email saying "hey, we're thinking about setting things up so that jsonb and hstore have the same binary format, but you can't index jsonb directly, you have to cast it to hstore, is everyone OK with that?" someone would have written back and said "no, that sounds nuts". The reason why input on that particular aspect of the design was not forthcoming isn't because everyone was OK with it; it's because it was never clearly spelled out. Maybe someone will say that this was discussed at last year's PGCon unconference, but surely everyone here knows that a discussion at an unconference 8 months ago doesn't substitute for a discussion on-list. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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 make it into core because of the json precedent but the entire > purpose of the extension system is stop dumping everything in the > public namespace. Stuff 'in core' becomes locked in stone, forever, > because of backwards compatibility concerns, which are IMNSHO, a > bigger set of issues than even pg_upgrade related issues. Have we > gone through all the new hstore functions and made sure they don't > break existing applications? Putting things in core welds your only > escape hatch shut. > > *All* non-sql standard types ought to be in extensions in an ideal world. I have seen your opinion on this but there have been enough counter-arguments that I am not ready to head in that direction. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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? So it's not really a problem unless the type we wanted to move into (or out of) core was itself composite. Sure, although that's not entirely impossible to imagine. I admit it seems less likely, and I could accept it as a restriction if we conquered the general case. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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 unless the type we wanted to move into (or out of) core was itself composite. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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 this a pg_upgrade-only problem? Can this be >>> fixed? > >> Yes, pg_upgrade is the problem, and no, I can't see how it can be fixed. > >> Builtin types have Oids in a certain range. Non-builtin types have Oids >> outside that range. If you have a clever way to get over that I'd be all >> ears, but it seems to me insurmountable right now. > > More to the point: > > 1. Built-in types have predetermined, fixed OIDs. Types made by > extensions do not, and almost certainly will have different OIDs in > different existing databases. > > 2. There's no easy way to change the OID of an existing type during > pg_upgrade, because it may be on-disk in (at least) array headers. > > We could possibly get around #2, if we could think of a secure way > for array_out and sibling functions to identify the array type > without use of the embedded OID value. I don't know how we could > do that though, particularly in polymorphic-function contexts. > > Also, there might be other cases besides arrays where we've embedded > type OIDs in on-disk data; anyone remember? composite types. merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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? > Yes, pg_upgrade is the problem, and no, I can't see how it can be fixed. > Builtin types have Oids in a certain range. Non-builtin types have Oids > outside that range. If you have a clever way to get over that I'd be all > ears, but it seems to me insurmountable right now. More to the point: 1. Built-in types have predetermined, fixed OIDs. Types made by extensions do not, and almost certainly will have different OIDs in different existing databases. 2. There's no easy way to change the OID of an existing type during pg_upgrade, because it may be on-disk in (at least) array headers. We could possibly get around #2, if we could think of a secure way for array_out and sibling functions to identify the array type without use of the embedded OID value. I don't know how we could do that though, particularly in polymorphic-function contexts. Also, there might be other cases besides arrays where we've embedded type OIDs in on-disk data; anyone remember? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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 the extension system is stop dumping everything in the public namespace. Stuff 'in core' becomes locked in stone, forever, because of backwards compatibility concerns, which are IMNSHO, a bigger set of issues than even pg_upgrade related issues. Have we gone through all the new hstore functions and made sure they don't break existing applications? Putting things in core welds your only escape hatch shut. *All* non-sql standard types ought to be in extensions in an ideal world. merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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, and no, I can't see how it can be fixed. Builtin types have Oids in a certain range. Non-builtin types have Oids outside that range. If you have a clever way to get over that I'd be all ears, but it seems to me insurmountable right now. A year or two ago I made a suggestion to help avoid such problems in future, but as Josh said it got shot down, and in any case it would not have helped with existing types such as hstore. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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 folks out there have apps already built against > hstore1 and they're going to keep on the hstore path. > > In the discussion you haven't apparently caught up on yet, we did > discuss moving *hstore* into core to make this whole thing easier. > However, that fell afoul of the fact that we currently have no mechanism > to move types between extensions and core without breaking upgrades for > everyone. So the only reason hstore is still an extension is because of > backwards-compatibility. I have read last week's thread on this issue, and it certainly seems we are in a non-ideal situation here. The discussion centered around the split of JSONB in core and hstore in contrib, the reason for some of these decisions, and what can make it into PG 9.4. I would like to take a different approach and explore what we _eventually_ want, then back into what we have and what can be done for 9.4. Basically, it seems we have heirchical hstore and JSONB which are identical except for the input/output syntax. Many are confused how a code split like that works long-term, and whether decisions made for 9.4 might limit future options. There seems to be a basic tension that we can't move hstore into core, must maintain backward-compatibility for hstore, and we want JSONB in core. Long-term, having JSON in core and JSONB in contrib seems quite odd. 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, I am ignoring what might be possible for 9.4, but I think these questions must be asked if we are going to properly plan for post-9.4 changes. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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 at all. > Actually, I didn't know any such thing. Just a couple days ago, you were arguing fairly strongly for moving jsonb to the hstore extension. You weren't clear that you'd given up on that line of argument. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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 if each corresponding elements of them are equal. postgres=# select 'a=>[]'::hstore = 'a=>[]'::hstore; ?column? -- t (1 row) Time: 0,576 ms postgres=# select 'a=>[0]'::hstore = 'a=>[0]'::hstore; ?column? -- t (1 row) Time: 0,663 ms postgres=# select 'a=>[0]'::hstore = 'a=>[1]'::hstore; ?column? -- f -- 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 to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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 numeric value. As I can see, it provides needed trim > and doesn't depend on locale. Possible mismatch (the same hash value for > different numeric valye) will rechecked anyway - interested operations set > recheck flag. huh. what it is the standard for equivalence? I guess we'd be following javascript ===, right? (http://dorey.github.io/JavaScript-Equality-Table/). merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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 depend on locale. Possible mismatch (the same hash value for different numeric valye) will rechecked anyway - interested operations set recheck flag. -- 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 to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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 there are other similar problems, such as differences in lc_numeric settings that your implementation cannot possibly account for. If that's not what you meant, I think it's okay if there are apparent trailing zeroes output under similar circumstances to the numeric type proper. Isn't this kind of thing intentionally not described by the relevant spec anyway? -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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 to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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 inconsistent >> will be fixed. > > Cool. > > > -- > Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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. Perhaps this is obvious, but: I expect that you intend to fix the inconsistency by having everywhere use a native numeric comparison. Thanks -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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 need explicitly point type of compare to prevent unpredictable > result. That's what I meant, I think. But I'm not sure what you mean: Native Chrome JavaScript. Copyright (c) 2013 Google Inc 25 == 25 => true 25 == 25.0 => true -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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
numeric_cmp() instead of comparing text representation. This inconsistent will
be fixed.
--
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 to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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 JavaScript (which was a base for json type) you need
explicitly point type of compare to prevent unpredictable result.
select '25.0'::numeric = '25'::numeric;
?column?
--
t
but
select '25.0'::numeric::text = '25'::numeric::text;
?column?
--
f
and
select '{"a": 25}'::json->>'a' = '{"a": 25.0}'::json->>'a';
?column?
--
f
In pointed example inserted value has age: 25 but searching jsonb value has
age:25.0.
+ CREATE OPERATOR CLASS gin_hstore_ops
+ DEFAULT FOR TYPE hstore USING gin
+ AS
+ OPERATOR7 @>,
+ OPERATOR9 ?(hstore,text),
+ OPERATOR10 ?|(hstore,text[]),
+ OPERATOR11 ?&(hstore,text[]),
+ FUNCTION1 bttextcmp(text,text),
+ FUNCTION2 gin_extract_hstore(internal, internal),
+ FUNCTION3 gin_extract_hstore_query(internal,
internal, int2, internal, internal),
+ FUNCTION4 gin_consistent_hstore(internal, int2,
internal, int4, internal, internal),
+ STORAGE text;
--
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 to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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 @>, + OPERATOR9 ?(hstore,text), + OPERATOR10 ?|(hstore,text[]), + OPERATOR11 ?&(hstore,text[]), + FUNCTION1 bttextcmp(text,text), + FUNCTION2 gin_extract_hstore(internal, internal), + FUNCTION3 gin_extract_hstore_query(internal, internal, int2, internal, internal), + FUNCTION4 gin_consistent_hstore(internal, int2, internal, int4, internal, internal), + STORAGE text; -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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 "public.bar"
> Column | Type | Modifiers | Storage | Stats target | Description
> +---+---+--+--+-
> i | jsonb | | extended | |
> Indexes:
> "f" gin (i)
> Has OIDs: no
>
> [local]/postgres=# insert into bar values ('{
> "firstName": "John",
> "lastName": "Smith",
> "age": 25,
> "address": {
> "streetAddress": "21 2nd Street",
> "city": "New York",
> "state": "NY",
> "postalCode": 10021
> },
> "phoneNumbers": [
> {
> "type": "home",
> "number": "212 555-1234"
> },
> {
> "type": "fax",
> "number": "646 555-4567"
> }
> ]
> }');
> INSERT 0 1
> Time: 7.635 ms
> [local]/postgres=# select * from bar where i @> '{"age":25.0}'::jsonb;
> i
> ---
> (0 rows)
>
> Time: 2.443 ms
> [local]/postgres=# explain select * from bar where i @> '{"age":25.0}'::jsonb;
>QUERY PLAN
> -
> Bitmap Heap Scan on bar (cost=16.01..20.02 rows=1 width=32)
>Recheck Cond: ((i)::hstore @> '"age"=>25.0'::hstore)
>-> Bitmap Index Scan on f (cost=0.00..16.01 rows=1 width=0)
> Index Cond: ((i)::hstore @> '"age"=>25.0'::hstore)
> Planning time: 0.161 ms
> (5 rows)
>
> [local]/postgres=# set enable_bitmapscan = off;
> SET
> Time: 6.052 ms
> [local]/postgres=# select * from bar where i @> '{"age":25.0}'::jsonb;
> -[ RECORD 1
> ]
> i | {"age": 25, "address": {"city": "New York", "state": "NY",
> "postalCode": 10021, "streetAddress": "21 2nd Street"}, "lastName":
> "Smith", "firstName": "John", "phoneNumbers": [{"type": "home",
> "number": "212 555-1234"}, {"type": "fax", "number": "646 555-4567"}]}
>
> Time: 6.479 ms
> [local]/postgres=# explain select * from bar where i @> '{"age":25.0}'::jsonb;
> QUERY PLAN
> -
> Seq Scan on bar (cost=0.00..26.38 rows=1 width=32)
>Filter: ((i)::hstore @> '"age"=>25.0'::hstore)
> Planning time: 0.154 ms
> (3 rows)
>
> Time: 6.565 ms
>
> --
> Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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
+---+---+--+--+-
i | jsonb | | extended | |
Indexes:
"f" gin (i)
Has OIDs: no
[local]/postgres=# insert into bar values ('{
"firstName": "John",
"lastName": "Smith",
"age": 25,
"address": {
"streetAddress": "21 2nd Street",
"city": "New York",
"state": "NY",
"postalCode": 10021
},
"phoneNumbers": [
{
"type": "home",
"number": "212 555-1234"
},
{
"type": "fax",
"number": "646 555-4567"
}
]
}');
INSERT 0 1
Time: 7.635 ms
[local]/postgres=# select * from bar where i @> '{"age":25.0}'::jsonb;
i
---
(0 rows)
Time: 2.443 ms
[local]/postgres=# explain select * from bar where i @> '{"age":25.0}'::jsonb;
QUERY PLAN
-
Bitmap Heap Scan on bar (cost=16.01..20.02 rows=1 width=32)
Recheck Cond: ((i)::hstore @> '"age"=>25.0'::hstore)
-> Bitmap Index Scan on f (cost=0.00..16.01 rows=1 width=0)
Index Cond: ((i)::hstore @> '"age"=>25.0'::hstore)
Planning time: 0.161 ms
(5 rows)
[local]/postgres=# set enable_bitmapscan = off;
SET
Time: 6.052 ms
[local]/postgres=# select * from bar where i @> '{"age":25.0}'::jsonb;
-[ RECORD 1
]
i | {"age": 25, "address": {"city": "New York", "state": "NY",
"postalCode": 10021, "streetAddress": "21 2nd Street"}, "lastName":
"Smith", "firstName": "John", "phoneNumbers": [{"type": "home",
"number": "212 555-1234"}, {"type": "fax", "number": "646 555-4567"}]}
Time: 6.479 ms
[local]/postgres=# explain select * from bar where i @> '{"age":25.0}'::jsonb;
QUERY PLAN
-
Seq Scan on bar (cost=0.00..26.38 rows=1 width=32)
Filter: ((i)::hstore @> '"age"=>25.0'::hstore)
Planning time: 0.154 ms
(3 rows)
Time: 6.565 ms
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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 much as I could given the time constraints I mentioned. That's the > way Postgres works. People do what they can. It would be such a small amount of additional effort to add those operators sufficient to make those operator classes work, relative to the huge benefits. The code already exists, there isn't terribly much of it, and is isn't scarier than what you already have. I cannot fathom how you could choose to not do so, as long as you wanted a jsonb type in core. It is just not sensible. >> But the equivalent code to the proposed hstore operator classes is >> *exactly the same* C code. The two types are fully binary coercible in >> the patch, so why delay? Why is that additional step appreciably >> riskier than adopting jsonb? I don't see why the functions associated >> with the operators that comprise, say, the gin_hstore_ops operator >> class represent much additional risk, assuming that jsonb is itself in >> good shape. For example, the new hstore_contains() looks fairly >> innocuous compared to much of the code you are apparently intent on >> including in the first cut at jsonb. Have I missed something? Why are >> those operators riskier than the operators you are intent on >> including? > > > > You are really jumping at conclusions as to what's in my head, conclusions > that are not justified by anything I have said. Right - they are conclusions justified by what you have not said, and my attempt to fill in the gaps. > Who said they were riskier? I certainly didn't. > > Of course the operators would be the same. We could have them today, by > migrating the exisiting code into core and making the hstore operators use > that code instead. I could probably do it in about a day (if I had a day to > spare). I was actually rather expecting that they would have been put there > for the jsonb type when Teodor moved some code so we could have a jsonb > type. But since he didn't we find ourselves where we are today. > > If that's what it will take to get agreement I will try to make it happen. I'll do it if you really are that strapped for time. > Well, the trouble is that the only one that would make sense is one that did > in effect "order by i::json", since it would be weird to have these > different. That might make the ordering slow, but would be easy enough to > add. No, it would not be weird to have those be different. In some cases it would be totally mandatory, as for example when there is a variable lc_numeric setting that affects the format of numeric. Only text equality is equivalent to a binary string comparison. > I think you need to be more accepting of the fact that Postgres development > is frequently incremental. Nothing that's been proposed would prevent future > development of the type AFAICT. Enums took us two or three releases to get > to where we are. Arrays took longer. Even a smallish feature like CSV import > is still being tweaked about seven releases after it was introduced. My objection is that the cost/benefit analysis behind the idea of excluding the hstore operator classes seem to make no sense. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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 if we're going to change course, we need a specific reason to change course, not just "it seems like a better idea now" or "I wasn't paying attention then". I'm pretty sure it doesn't work like that. But if it does, what exactly am I insisting on that is inconsistent with that consensus? In what way are we changing course? I think I'm being eminently flexible. I don't want a jsonb type that is broken, as for example by not having a default B-Tree operator class. Why don't you let me get on with it? You're welcome to submit any code you like. We haven't been secret about where the code lives. Nobody is stopping you. What you're not welcome to do, from my POV, is move jsonb into the hstore extension. I strenuously object to any such plan. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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 say "well I'll have to use json because it lacks function x." For the processing functions, i.e. those that don't generate json from non-json, this should be true with what's proposed. The jsonb processing functions should be about as fast as, or in some cases significantly faster than, their json equivalents. Parsing text input takes a little longer (surprisingly little, actually), and reserializing takes significantly longer - I haven't had a chance to look and see if we can improve that. Both of these are more or less expected results. 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 much as I could given the time constraints I mentioned. That's the way Postgres works. People do what they can. For 9.5 I would hope that we have at least the equivalent of the proposed hstore classes. But the equivalent code to the proposed hstore operator classes is *exactly the same* C code. The two types are fully binary coercible in the patch, so why delay? Why is that additional step appreciably riskier than adopting jsonb? I don't see why the functions associated with the operators that comprise, say, the gin_hstore_ops operator class represent much additional risk, assuming that jsonb is itself in good shape. For example, the new hstore_contains() looks fairly innocuous compared to much of the code you are apparently intent on including in the first cut at jsonb. Have I missed something? Why are those operators riskier than the operators you are intent on including? You are really jumping at conclusions as to what's in my head, conclusions that are not justified by anything I have said. Who said they were riskier? I certainly didn't. Of course the operators would be the same. We could have them today, by migrating the exisiting code into core and making the hstore operators use that code instead. I could probably do it in about a day (if I had a day to spare). I was actually rather expecting that they would have been put there for the jsonb type when Teodor moved some code so we could have a jsonb type. But since he didn't we find ourselves where we are today. If that's what it will take to get agreement I will try to make it happen. If it is true that you think that's a significant additional risk, a risk too far, then it makes sense that you'd defer doing this. I would like to know why that is, though, since I don't see it. I don't, as I said. This whole line of speculation has me quite puzzled. Speaking of missing operator classes, I'm pretty sure that it's ipso facto unacceptable that there is no default btree operator class for the type jsonb: [local]/postgres=# \d+ bar Table "public.bar" Column | Type | Modifiers | Storage | Stats target | Description +---+---+--+--+- i | jsonb | | extended | | Has OIDs: no [local]/postgres=# select * from bar order by i; ERROR: 42883: could not identify an ordering operator for type jsonb LINE 1: select * from bar order by i; ^ HINT: Use an explicit ordering operator or modify the query. LOCATION: get_sort_group_operators, parse_oper.c:221 Time: 6.424 ms [local]/postgres=# select distinct i from bar; ERROR: 42883: could not identify an equality operator for type jsonb LINE 1: select distinct i from bar; ^ LOCATION: get_sort_group_operators, parse_oper.c:226 Time: 6.457 ms Well, the trouble is that the only one that would make sense is one that did in effect "order by i::json", since it would be weird to have these different. That might make the ordering slow, but would be easy enough to add. 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'd like to be able to index jsonb's #> and #>> operators, for example. Unanchored subpath operators could be an area that's interesting to implement and index. I'm sure that's true, but it's not our immediate concern. We need to think very hard about it to get everything we want, but we also need to think somewhat harder about it in order to get even a basic jsonb type committed. I think you need to be more accepting of the fact that Postgres development is frequently incremental. Nothing that's been proposed would prevent future development of the type AFAICT. Enums took
Re: [HACKERS] jsonb and nested hstore
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 specific reason to change course, not just > "it seems like a better idea now" or "I wasn't paying attention then". I'm pretty sure it doesn't work like that. But if it does, what exactly am I insisting on that is inconsistent with that consensus? In what way are we changing course? I think I'm being eminently flexible. I don't want a jsonb type that is broken, as for example by not having a default B-Tree operator class. Why don't you let me get on with it? -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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'd like to be able to index jsonb's #> and #>> operators, >> for example. Unanchored subpath operators could be an area that's >> interesting to implement and index. > > I'm sure that's true, but it's not our immediate concern. We need to > think very hard about it to get everything we want, but we also need > to think somewhat harder about it in order to get even a basic jsonb > type committed. By the way, I think it would be fine to defer adding many of the new hstore operators and functions until 9.5 (as hstore infrastructure, or in-core jsonb infrastructure, or anything else), if you felt you had to, provided that you included just those sufficient to create jsonb operator classes (plus the operator classes themselves, of course). There is absolutely no question about having to do this for B-Tree...why not go a couple of operator classes further? -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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 lacks function x." For the processing functions, i.e. > those that don't generate json from non-json, this should be true with > what's proposed. The jsonb processing functions should be about as fast as, > or in some cases significantly faster than, their json equivalents. Parsing > text input takes a little longer (surprisingly little, actually), and > reserializing takes significantly longer - I haven't had a chance to look > and see if we can improve that. Both of these are more or less expected > results. 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. > For 9.5 I would hope that we have at least the equivalent of the proposed > hstore classes. But the equivalent code to the proposed hstore operator classes is *exactly the same* C code. The two types are fully binary coercible in the patch, so why delay? Why is that additional step appreciably riskier than adopting jsonb? I don't see why the functions associated with the operators that comprise, say, the gin_hstore_ops operator class represent much additional risk, assuming that jsonb is itself in good shape. For example, the new hstore_contains() looks fairly innocuous compared to much of the code you are apparently intent on including in the first cut at jsonb. Have I missed something? Why are those operators riskier than the operators you are intent on including? If it is true that you think that's a significant additional risk, a risk too far, then it makes sense that you'd defer doing this. I would like to know why that is, though, since I don't see it. Speaking of missing operator classes, I'm pretty sure that it's ipso facto unacceptable that there is no default btree operator class for the type jsonb: [local]/postgres=# \d+ bar Table "public.bar" Column | Type | Modifiers | Storage | Stats target | Description +---+---+--+--+- i | jsonb | | extended | | Has OIDs: no [local]/postgres=# select * from bar order by i; ERROR: 42883: could not identify an ordering operator for type jsonb LINE 1: select * from bar order by i; ^ HINT: Use an explicit ordering operator or modify the query. LOCATION: get_sort_group_operators, parse_oper.c:221 Time: 6.424 ms [local]/postgres=# select distinct i from bar; ERROR: 42883: could not identify an equality operator for type jsonb LINE 1: select distinct i from bar; ^ LOCATION: get_sort_group_operators, parse_oper.c:226 Time: 6.457 ms > 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'd like to be able to index jsonb's #> and #>> operators, > for example. Unanchored subpath operators could be an area that's > interesting to implement and index. I'm sure that's true, but it's not our immediate concern. We need to think very hard about it to get everything we want, but we also need to think somewhat harder about it in order to get even a basic jsonb type committed. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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 all that concerned about what the > least worst way of doing that is (I just favor putting everything in > hstore on practical grounds). Well, I don't see how this is "on practical grounds" at this point. Whether we keep jsonb in core or not, we have an equal amount of work ahead of us. That's why I said the single-extension approach was "conceptually simpler" rather than "actually simpler". It's easier to understand, not necessarily easier to implement at this point. 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 specific reason to change course, not just "it seems like a better idea now" or "I wasn't paying attention then". The "one extension to rule them all" approach also has the issue of Naming Things, but I think that could be solved with a symlink or two. > Another way to solve this problem might > be to simply live with the code duplication between core and hstore on What code duplication? > the grounds that hstore will eventually be deprecated as people switch > to jsonb over time (so under that regime nothing new would ever be > added to hstore, which we'd eventually remove from contrib entirely, > while putting everything new here in core). I don't favor that > approach, but it wouldn't be totally unreasonable, based on the > importance that is attached to jsonb, and based on what I'd estimate > to be the actual amount of code redundancy that that would create > (assuming that hstore gets no new functions and operators, since an > awful lot of the hstore-local code after this patch is applied is new > to hstore). I wouldn't stand in the way of this approach. 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 folks out there have apps already built against hstore1 and they're going to keep on the hstore path. In the discussion you haven't apparently caught up on yet, we did discuss moving *hstore* into core to make this whole thing easier. However, that fell afoul of the fact that we currently have no mechanism to move types between extensions and core without breaking upgrades for everyone. So the only reason hstore is still an extension is because of backwards-compatibility. > In my view the most important thing right now is that before anything > is committed, at the very least there needs to be a strategy around > getting hstore-style GIN indexing in jsonb. I think it's a good idea to have a strategy. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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 purposes of hstore-style indexing (the hstore operator classes). Wasn't that the point? When there is a dedicated set of jsonb operator classes, what will be different about them, other than the fact that they won't be hstore operator classes? A decision predicated on waiting for those to come in 9.5 must consider what we're actually waiting for, and right now that seems very hazy. I really would like an answer to this question. Even if I totally agreed with Andrew's assessment of the relative importance of having jsonb be an in-core type, versus having some more advanced indexing capabilities right away, this is still a very salient question. (Taking a break from some frantic customer work) 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 lacks function x." For the processing functions, i.e. those that don't generate json from non-json, this should be true with what's proposed. The jsonb processing functions should be about as fast as, or in some cases significantly faster than, their json equivalents. Parsing text input takes a little longer (surprisingly little, actually), and reserializing takes significantly longer - I haven't had a chance to look and see if we can improve that. Both of these are more or less expected results. For 9.5 I would hope that we have at least the equivalent of the proposed hstore classes. 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'd like to be able to index jsonb's #> and #>> operators, for example. Unanchored subpath operators could be an area that's interesting to implement and index. I also would like to see some basic insert/update/delete/merge operators for json/jsonb - that's an area I wanted to work on for this lease but wasn't able to arrange. Note that future developments is a major topic of my pgcon talk, and I'm hoping that we can get some good discussion going there. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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 9.5 - it's a big project. Nor is it obvious to me that a >> VODKA-ized set of operator classes would not bring with them exactly >> the same dilemma as we now face vis-a-vis hstore code reuse and GIN >> operator classes. So it seems reasonable to me to suppose that VODKA >> should not influence our decision here. Please correct me if I'm >> mistaken. > > I would agree with you. 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 all that concerned about what the least worst way of doing that is (I just favor putting everything in hstore on practical grounds). Another way to solve this problem might be to simply live with the code duplication between core and hstore on the grounds that hstore will eventually be deprecated as people switch to jsonb over time (so under that regime nothing new would ever be added to hstore, which we'd eventually remove from contrib entirely, while putting everything new here in core). I don't favor that approach, but it wouldn't be totally unreasonable, based on the importance that is attached to jsonb, and based on what I'd estimate to be the actual amount of code redundancy that that would create (assuming that hstore gets no new functions and operators, since an awful lot of the hstore-local code after this patch is applied is new to hstore). I wouldn't stand in the way of this approach. In my view the most important thing right now is that before anything is committed, at the very least there needs to be a strategy around getting hstore-style GIN indexing in jsonb. I cannot understand how you can have an operator class today that works fine for hstore-style indexing of jsonb (as far as that goes), but that that code is out of bounds just because it's nominally (mostly new) hstore code, and you cannot figure out a way of making that work that is acceptable from a code maintenance perspective. If you cannot figure that out in a few days, why should you ever be able to figure it out? We need to bite the bullet here, whatever that might actually entail. Can we agree on that much? -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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 > VODKA-ized set of operator classes would not bring with them exactly > the same dilemma as we now face vis-a-vis hstore code reuse and GIN > operator classes. So it seems reasonable to me to suppose that VODKA > should not influence our decision here. Please correct me if I'm > mistaken. I would agree with you. Andrew was onsite with a client over the weekend, which is why you haven't heard from him on this thread. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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 classes included in >> these patches. However, surely these hstore operator classes have >> independent value, or represent incremental progress? > > 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 VODKA-ized set of operator classes would not bring with them exactly the same dilemma as we now face vis-a-vis hstore code reuse and GIN operator classes. So it seems reasonable to me to suppose that VODKA should not influence our decision here. Please correct me if I'm mistaken. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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 hstore operator classes have > independent value, or represent incremental progress? Primary value is that in theory the hstore2 opclasses are available *now*, as opposed to a year from now. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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 hstore operator classes). Wasn't that the > point? When there is a dedicated set of jsonb operator classes, what > will be different about them, other than the fact that they won't be > hstore operator classes? A decision predicated on waiting for those to > come in 9.5 must consider what we're actually waiting for, and right > now that seems very hazy. I really would like an answer to this question. Even if I totally agreed with Andrew's assessment of the relative importance of having jsonb be an in-core type, versus having some more advanced indexing capabilities right away, this is still a very salient question. I appreciate that the "put jsonb in hstore extension to get indexing right away" trade-off is counter-intuitive, and it may even be that there is an "everybody wins" third way that sees us factor out code that is common to both jsonb and hstore as it exists today (although I'm not optimistic about that). I would like to emphasize that if you want to defer working on hstore-style jsonb operator classes for one release, I don't necessarily have a problem with that. But, I must insist on an answer here, from either you or Oleg or Teodor (it isn't apparent that Oleg and Teodor concur with you on what's important): what did we run out of time for? What will be different about the jsonb operator classes that you're asking us to wait for in a future release? 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 hstore operator classes have independent value, or represent incremental progress? -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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, you well assume otherwise! My Chinese wife sometimes corrects my English, and from time to time she is right! To the extent that I've read the postings of non-native English speakers like Oleg & Andres, I've not noticed any difficulty understanding what they meant - other than technical issues that would also be the same for me from gifted native English speakers! Cheers, Gavin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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 have look sometime soon. > >> We are not native-english and may not well inderstand your criticism >> well, but please try to be a little bit polite. We are working >> together and our common goal is to make postgres better. Your notes >> are very important for quality of postgres, but sometimes you drive us >> ... > > I am sorry if I came over as impolite. I just tried to point at things I > thought needed improvement, and imo there were quite some. A patch > needing polishing isn't something that carries shame, blame or > anything. It's just a state a patch can be in. We have not so much time to go deep onto 100th messages threads and sometimes just lost directions. > > Greetings, > > Andres Freund > > PS: Not a native speaker either... That's explain all :) > > -- > Andres Freund http://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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 inderstand your criticism > well, but please try to be a little bit polite. We are working > together and our common goal is to make postgres better. Your notes > are very important for quality of postgres, but sometimes you drive us > ... I am sorry if I came over as impolite. I just tried to point at things I thought needed improvement, and imo there were quite some. A patch needing polishing isn't something that carries shame, blame or anything. It's just a state a patch can be in. Greetings, Andres Freund PS: Not a native speaker either... -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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. You last issues were addressed in both branches. Oleg PS. We are not native-english and may not well inderstand your criticism well, but please try to be a little bit polite. We are working together and our common goal is to make postgres better. Your notes are very important for quality of postgres, but sometimes you drive us ... On Mon, Mar 3, 2014 at 7:00 PM, Andres Freund wrote: > 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 crossread both patches I tend to agree with this. I don't think >> > it's unrealistic to get jsonb committable, but the hstore bits are >> > another story. >> >> hm, do you have any specific concerns/objections about hstore? > > I've listed a fair number in various emails, some have been addressed > since I think. But just take a look at the patch, at least last when I > looked, it was simply far from ready. And it's quite a bit of code, so > it's not something that can be addressed within 5min. > > Greetings, > > Andres Freund > > -- > Andres Freund http://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Training & Services > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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 crossread both patches I tend to agree with this. I don't think > > it's unrealistic to get jsonb committable, but the hstore bits are > > another story. > > hm, do you have any specific concerns/objections about hstore? I've listed a fair number in various emails, some have been addressed since I think. But just take a look at the patch, at least last when I looked, it was simply far from ready. And it's quite a bit of code, so it's not something that can be addressed within 5min. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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 > it's unrealistic to get jsonb committable, but the hstore bits are > another story. hm, do you have any specific concerns/objections about hstore? merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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 acceptable that jsonb be packaged in the hstore > extension. To put it mildly, there's no consensus on that point; indeed, I > think there's consensus that's a non-starter. No, it assumes nothing at all. It's a very simple question. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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 mildly, there's no consensus on that point; indeed, I think there's consensus that's a non-starter. -- -- Christophe Pettus x...@thebuild.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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 disappointing. 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 hstore operator classes). Wasn't that the point? When there is a dedicated set of jsonb operator classes, what will be different about them, other than the fact that they won't be hstore operator classes? A decision predicated on waiting for those to come in 9.5 must consider what we're actually waiting for, and right now that seems very hazy. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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 initially have indexing operations for it. -- -- Christophe Pettus x...@thebuild.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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 functionality by casting the data to hstore (assuming we > also have nested-hstore committed) and using its operators. But that's no > more a dependency than it is for any other type for which you can leverage > this functionality (e.g. any record type). I don't think hstore-style indexing is "advanced"; it's the main reason for there being a jsonb, in my view. Anyway, this is where I have a hard time understanding what you intend for jsonb for 9.4. You ran out of time for writing jsonb operator classes, and so you can use the hstore ones, which work fine. But, if we didn't run out of time, how would the jsonb operator classes differ from the hstore ones? Is there something inferior about the hstore operator class as compared to a hypothetical jsonb operator class, other than the superficial need to cast? -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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 > in -contrib can very well be telling them "You can't have it" in those cases. Amazon RDS Postgres has hstore. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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 pick what packages are installed on their server (RDS, for example). Telling them that something is in -contrib can very well be telling them "You can't have it" in those cases. -- -- Christophe Pettus x...@thebuild.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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 to hstore. I think that'll be a mess that will take years to undo. I'd rather say "sorry, that functionality isn't there yet for jsonb" than have such a dependency. Maybe we're in violent agreement. Maybe we are. There's actually no real dependency. In fact, the dependency is the other way. The jsonb patches I have been posting could be committed and pass every regression test and we'd have useful better performance for some operations. Every json function has an analog in jsonb except the generator functions (to_json and friends), and they use the same parser so they accept exactly the same input. 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 functionality by casting the data to hstore (assuming we also have nested-hstore committed) and using its operators. But that's no more a dependency than it is for any other type for which you can leverage this functionality (e.g. any record type). cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
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 with admins not wanting to install -contrib aren't really about what's in or not in -contrib. They're about: a) it's another package b) they don't understand what's in it c) it's called "contrib" which implies that these are untested/unreviewed scripts, or somehow relates to hacking on Postgres, both of which were true historically d) there's some wierd/unstable dependancies for certain contrib modules (UUID in particular) e) some vendors don't make contrib available because of the encryption thing (pgcrypto) All of the above are worth fixing, but we don't have a proposal on the table to do so. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
