On 02/27/2014 11:02 PM, Christophe Pettus wrote:
On Feb 27, 2014, at 9:59 PM, Peter Geoghegan p...@heroku.com wrote:
I don't find that very reassuring.
Obviously, we have to try it, and that will decide it.
I don't understand why an extension is seen as not befitting
of a more important
On Fri, Feb 28, 2014 at 8:57 AM, Stephen Frost sfr...@snowman.net wrote:
The specific issues mentioned on this thread look more like bugs to be
addressed or additional operators which need to be implemented for
jsonb (imv, that should really be done for 9.4, but we have this
deadline
+v.size += VARSIZE_ANY(v.numeric) +sizeof(JEntry) /* alignment */ ;
Why does + sizeof(JEntry) change anything about alignment? If it was
aligned before, adding a statically sized value doesn't give any new
guarantees about alignment?
Teodor, please comment.
Because numeric type
On Feb 28, 2014, at 6:27 AM, Robert Haas robertmh...@gmail.com wrote:
Taken individually, none of those decisions seem crazy, but taken
together it's pretty weird. Instead of inventing a new type (jsonb)
designed from the ground up to do what we want, we're, well, we're
doing what
On 02/28/2014 07:39 AM, Joshua D. Drake wrote:
This is an old and currently false argument. It is true that once upon a
time, contrib was a banished heart, weeping for the attention of a true
prince. Now? Not so much. She is a full on passion flower with the
princes of all the kingdoms
On Fri, Feb 28, 2014 at 5:01 AM, Andrew Dunstan and...@dunslane.net wrote:
But anyway, I think we've seen enough of these to conclude that the casts
from hstore to jsonb and back should not be implicit. I am fairly confident
that changing that would fix your complaint and the similar one that
Peter Geoghegan p...@heroku.com writes:
On Fri, Feb 28, 2014 at 5:01 AM, Andrew Dunstan and...@dunslane.net wrote:
But anyway, I think we've seen enough of these to conclude that the casts
from hstore to jsonb and back should not be implicit. I am fairly confident
that changing that would fix
On 02/28/2014 06:27 AM, Robert Haas wrote:
Taken individually, none of those decisions seem crazy, but taken
together it's pretty weird. Instead of inventing a new type (jsonb)
designed from the ground up to do what we want, we're, well, we're
doing what Christophe says: creating our own
On Fri, Feb 28, 2014 at 7:12 PM, Josh Berkus j...@agliodbs.com 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.
--
greg
--
Sent via pgsql-hackers mailing list
On 02/28/2014 02:00 PM, Tom Lane wrote:
Peter Geoghegan p...@heroku.com writes:
On Fri, Feb 28, 2014 at 5:01 AM, Andrew Dunstan and...@dunslane.net wrote:
But anyway, I think we've seen enough of these to conclude that the casts
from hstore to jsonb and back should not be implicit. I am
Josh Berkus j...@agliodbs.com writes:
... This requires larger changes to the existing patch, which likely means
missing the bus for 9.4 (and you've seen my blog about that)
Yeah. I realize you're gung-ho about getting jsonb into 9.4 in some
form, and I recognize that getting better JSON
On Fri, Feb 28, 2014 at 11:12 AM, Josh Berkus j...@agliodbs.com wrote:
I think Robert and Christophe are right: we're building a Berkeley BART
Curve. I think there's two courses of action from here which make sense:
A) We move *all* of the important HStore libraries and operators into
core,
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
On 02/28/2014 02:46 PM, Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
... This requires larger changes to the existing patch, which likely means
missing the bus for 9.4 (and you've seen my blog about that)
Yeah. I realize you're gung-ho about getting jsonb into 9.4 in some
form, and
Andrew Dunstan and...@dunslane.net 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
On Fri, Feb 28, 2014 at 1:45 PM, Andrew Dunstan and...@dunslane.net wrote:
Well, the jsonb portion of this is arguably the most ready, certainly it's
had a lot more on-list review.
That is definitely true. Also, the jsonb type does not introduce any
new patterns that are not already covered
On 02/28/2014 11:19 AM, Greg Stark wrote:
On Fri, Feb 28, 2014 at 7:12 PM, Josh Berkus j...@agliodbs.com 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,
On 02/28/2014 03:19 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net 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
On Feb 28, 2014, at 1:03 PM, Josh Berkus j...@agliodbs.com 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
On Fri, Feb 28, 2014 at 1:31 PM, Christophe Pettus x...@thebuild.com 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
On Fri, Feb 28, 2014 at 1:25 PM, Andrew Dunstan and...@dunslane.net 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
On Feb 28, 2014, at 1:35 PM, Peter Geoghegan p...@heroku.com 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
On Feb 28, 2014, at 1:34 PM, Peter Geoghegan p...@heroku.com 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
On Fri, Feb 28, 2014 at 1:38 PM, Christophe Pettus x...@thebuild.com 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
On Feb 28, 2014, at 2:12 PM, Peter Geoghegan p...@heroku.com 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.
On Fri, Feb 28, 2014 at 2:40 PM, Christophe Pettus x...@thebuild.com wrote:
On Feb 28, 2014, at 2:12 PM, Peter Geoghegan p...@heroku.com wrote:
AFAICT, we have these
operator classes that work fine with jsonb for the purposes of
hstore-style indexing (the hstore operator classes).
That
On Wed, Feb 26, 2014 at 7:42 PM, Andrew Dunstan and...@dunslane.net wrote:
The jsonb set will get larger as time goes on. I don't think either of you
are thinking very clearly about how we would do this. Extensions can't call
each other's code. So the whole notion we have here of sharing the
On 02/26/2014 09:17 AM, Christophe Pettus wrote:
On Feb 25, 2014, at 1:57 PM, Hannu Krosing ha...@2ndquadrant.com wrote:
It is not in any specs, but nevertheless all major imlementations do it and
some code depends on it.
I have no doubt that some code depends on it, but all major
On Wed, Feb 26, 2014 at 10:42 PM, Andrew Dunstan and...@dunslane.net wrote:
Why can't this whole thing be shipped as an extension? It might well
be more convenient to have the whole thing packaged as an extension
than to have parts of it in core and parts of it not in core.
That's a good
On Feb 27, 2014, at 3:54 AM, Robert Haas robertmh...@gmail.com wrote:
It's not very clear to me why we think it's a good idea to share the
tree-ish representation between json and hstore. In deference to your
comments that this has been very publicly discussed over quite a
considerable
On 02/27/2014 01:56 AM, Peter Geoghegan wrote:
I don't understand why you'd consider it to be a matter of shoehorning
jsonb into hstore (and yes, that is what I was suggesting).
Because the course Andrew is following is the one which *this list*
decided on in CF3, no matter that people who
On 02/26/2014 05:45 PM, Andres Freund wrote:
On 2014-02-26 16:23:12 -0500, Andrew Dunstan wrote:
On 02/10/2014 09:11 PM, Andres Freund wrote:
Is it just me or is jsonapi.h not very well documented?
What about it do you think is missing? In any case, it's hardly relevant to
this patch, so
On Thu, Feb 27, 2014 at 1:11 PM, Josh Berkus j...@agliodbs.com wrote:
However, we had this discussion already in November-December, which
resulted in the current patch. Now you and Robert want to change the
rules on Andrew, which means Andrew is ready to quit, and we go another
year without
On Thu, Feb 27, 2014 at 11:11 AM, Josh Berkus j...@agliodbs.com wrote:
Because the course Andrew is following is the one which *this list*
decided on in CF3, no matter that people who participated in that
discussion seem to have collective amnesia. There was a considerable
amount of effort
On Thu, Feb 27, 2014 at 3:54 AM, Robert Haas robertmh...@gmail.com wrote:
So I tried to tease it out from looking at the patches. As nearly as
I can tell, the reason for making jsonb use hstore's binary format is
because then we can build indexes on jsonbfield::hstore, and the
actual type
On Thu, Feb 27, 2014 at 1:28 PM, Merlin Moncure mmonc...@gmail.com wrote:
3) In it's current state jsonb is not very useful and we have to
recognize that; it optimizes text json but OTOH covers, maybe 30-40%
of what hstore offers. In particular, it's missing manipulation and
GIST/GIN. The
On 02/27/2014 01:28 PM, Merlin Moncure wrote:
How we got here is not the point. All that matters is what's going to
happen from here. Here are the facts as I see them:
Well, it certainly matters if we want it in this release.
As far as I can tell, moving jsonb to contrib basically requires
On Feb 27, 2014, at 5:31 PM, Peter Geoghegan p...@heroku.com wrote:
Now, it's confusing that it has to go through hstore, perhaps, but
that's hardly all that bad in and of itself.
Yes, it is. It strikes me as irrational to have jsonb depend on hstore. Let's
be honest with ourselves: if we
On 02/28/2014 09:54 AM, Josh Berkus wrote:
On 02/27/2014 01:28 PM, Merlin Moncure wrote:
How we got here is not the point. All that matters is what's going to
happen from here. Here are the facts as I see them:
Well, it certainly matters if we want it in this release.
As far as I can
On Thu, Feb 27, 2014 at 6:02 PM, Craig Ringer cr...@2ndquadrant.com wrote:
It's also make it a lot harder to use in other extensions, something
that's already an issue with hstore.
What do you mean?
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
* Peter Geoghegan (p...@heroku.com) wrote:
On Thu, Feb 27, 2014 at 6:02 PM, Craig Ringer cr...@2ndquadrant.com wrote:
It's also make it a lot harder to use in other extensions, something
that's already an issue with hstore.
What do you mean?
Extensions can't depend on other extensions
On Thu, Feb 27, 2014 at 6:08 PM, Stephen Frost sfr...@snowman.net wrote:
On Thu, Feb 27, 2014 at 6:02 PM, Craig Ringer cr...@2ndquadrant.com wrote:
It's also make it a lot harder to use in other extensions, something
that's already an issue with hstore.
What do you mean?
Extensions can't
* Peter Geoghegan (p...@heroku.com) wrote:
On Thu, Feb 27, 2014 at 6:08 PM, Stephen Frost sfr...@snowman.net wrote:
Extensions can't depend on other extensions directly- hence you can't
write an extension that depends on hstore, which sucks. It'd be
preferrable to not have that issue w/
On 2/27/14, 2:11 PM, Josh Berkus wrote:
This means that, if we have jsonb as an extension, we'll
eventually be in the position where the recommended json type with all
the features is an extension, whereas the legacy json type is in core.
Well that wouldn't be a new situation. Compare
On Thu, Feb 27, 2014 at 5:54 PM, Josh Berkus j...@agliodbs.com wrote:
And it's not just that broadly speaking most people would prefer
the interface to speak JSON; it's that a JSONish interface for indexed
heirachical data is a Big Feature which will drive adoption among web
developers, and
On 2/26/14, 10:42 PM, Andrew Dunstan wrote:
Extensions can't call each other's code.
That's not necessarily so.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2/27/14, 9:08 PM, Stephen Frost wrote:
Extensions can't depend on other extensions directly- hence you can't
write an extension that depends on hstore, which sucks.
Sure they can, see transforms.
(Or if you disagree, download that patch and demo it, because I'd like
to know. ;-) )
--
On 02/27/2014 10:09 PM, Peter Geoghegan wrote:
* It hardly makes any sense to have an in-core jsonb if it comes with
no batteries included. You need to install hstore for this jsonb
implementation to be of *any* use anyway.
This is complete nonsense. Right out of the box today a
On Thu, Feb 27, 2014 at 7:27 PM, Andrew Dunstan and...@dunslane.net wrote:
On 02/27/2014 10:09 PM, Peter Geoghegan wrote:
* It hardly makes any sense to have an in-core jsonb if it comes with
no batteries included. You need to install hstore for this jsonb
implementation to be of *any* use
Peter,
* Peter Eisentraut (pete...@gmx.net) wrote:
On 2/27/14, 9:08 PM, Stephen Frost wrote:
Extensions can't depend on other extensions directly- hence you can't
write an extension that depends on hstore, which sucks.
Sure they can, see transforms.
(Or if you disagree, download that
On Thu, Feb 27, 2014 at 8:05 PM, Stephen Frost sfr...@snowman.net wrote:
And, for my 2c, I'd like to see jsonb as a built-in type *anyway*. Even
if it's possible to fight with things and make inter-extension
dependency work, it's not trivial and would likely discourage new
developers trying
On Thu, Feb 27, 2014 at 8:07 PM, Peter Geoghegan p...@heroku.com wrote:
On Thu, Feb 27, 2014 at 8:05 PM, Stephen Frost sfr...@snowman.net wrote:
And, for my 2c, I'd like to see jsonb as a built-in type *anyway*. Even
if it's possible to fight with things and make inter-extension
dependency
On 02/27/2014 05:54 PM, Josh Berkus wrote:
And it's not just that broadly speaking most people would prefer
the interface to speak JSON; it's that a JSONish interface for indexed
heirachical data is a Big Feature which will drive adoption among web
developers, and hstore2 without JSON
On Feb 27, 2014, at 8:04 PM, Peter Geoghegan p...@heroku.com wrote:
I'm hearing a lot about how important jsonb is, but not much on how to
make the simple jsonb cases that are currently broken (as illustrated
by my earlier examples [1], [2]) work.
Surely, the answer is to define a jsonb ||
On Thu, Feb 27, 2014 at 8:23 PM, Christophe Pettus x...@thebuild.com wrote:
On Feb 27, 2014, at 8:04 PM, Peter Geoghegan p...@heroku.com wrote:
I'm hearing a lot about how important jsonb is, but not much on how to
make the simple jsonb cases that are currently broken (as illustrated
by my
On Feb 27, 2014, at 8:31 PM, Peter Geoghegan p...@heroku.com wrote:
On Thu, Feb 27, 2014 at 8:23 PM, Christophe Pettus x...@thebuild.com wrote:
Surely, the answer is to define a jsonb || jsonb (and likely the other
combinatorics of json and jsonb), along with the appropriate GIN and GiST
On 02/28/2014 12:43 PM, Christophe Pettus wrote:
My proposal is that we break the dependencies of jsonb (at least, at the
user-visible level) on hstore2, thus allowing it in core successfully. jsonb
|| jsonb returning hstore seems like a bug to me, not a feature we should be
supporting.
On Thu, Feb 27, 2014 at 8:43 PM, Christophe Pettus x...@thebuild.com wrote:
I'm not the one opposed to putting jsonb stuff in the hstore module!
My proposal is that we break the dependencies of jsonb (at least, at the
user-visible level) on
hstore2, thus allowing it in core successfully.
On Feb 27, 2014, at 9:12 PM, Craig Ringer cr...@2ndquadrant.com wrote:
On 02/28/2014 12:43 PM, Christophe Pettus wrote:
My proposal is that we break the dependencies of jsonb (at least, at the
user-visible level) on hstore2, thus allowing it in core successfully. jsonb
|| jsonb returning
On Feb 27, 2014, at 9:28 PM, Peter Geoghegan p...@heroku.com wrote:
The only problem with that is now you have to move the implementation
of ||, plus a bunch of other hstore operators into core. That seems
like a more difficult direction to move in from a practical
perspective, and I'm not
On Thu, Feb 27, 2014 at 9:35 PM, Christophe Pettus x...@thebuild.com wrote:
The only problem with that is now you have to move the implementation
of ||, plus a bunch of other hstore operators into core. That seems
like a more difficult direction to move in from a practical
perspective, and I'm
On 2014-02-27 22:10:22 -0500, Peter Eisentraut wrote:
On 2/26/14, 10:42 PM, Andrew Dunstan wrote:
Extensions can't call each other's code.
That's not necessarily so.
I don't think we have portable infrastructure to it properly yet,
without a detour via the fmgr. If I am wrong, what's the
On Feb 27, 2014, at 9:59 PM, Peter Geoghegan p...@heroku.com wrote:
I don't find that very reassuring.
Obviously, we have to try it, and that will decide it.
I don't understand why an extension is seen as not befitting
of a more important feature.
contrib/ is considered a secondary set of
On 02/28/2014 09:02 AM, Christophe Pettus wrote:
contrib/ is considered a secondary set of features; I routinely get pushback
from clients about using hstore because it's not in core, and they are thus
suspicious of it. The educational project required to change that far exceeds
any
On Thu, Feb 27, 2014 at 11:02 PM, Christophe Pettus x...@thebuild.com wrote:
On Feb 27, 2014, at 9:59 PM, Peter Geoghegan p...@heroku.com wrote:
I don't find that very reassuring.
Obviously, we have to try it, and that will decide it.
I don't think that's obvious at all. Anyone is free to
On Feb 27, 2014, at 11:15 PM, Peter Geoghegan p...@heroku.com wrote:
I don't think that's obvious at all. Anyone is free to spend their
time however they please, but personally I don't think that that's a
wise use of anyone's time.
I believe you are misunderstanding me. If there are actual
On Thu, Feb 27, 2014 at 11:36 PM, Christophe Pettus x...@thebuild.com wrote:
There was no technical reason that json couldn't have been an extension,
either, but there were very compelling presentational reasons to have it in
core. jsonb has exactly the same presentational issues.
There
On Tue, Feb 25, 2014 at 10:07 PM, Craig Ringer cr...@2ndquadrant.com wrote:
On 02/26/2014 06:21 AM, Merlin Moncure wrote:
On Tue, Feb 25, 2014 at 4:03 PM, Josh Berkus j...@agliodbs.com wrote:
On 02/25/2014 12:12 PM, Robert Haas wrote:
I don't agree that jsonb should be preferred in all but a
On Tue, Feb 25, 2014 at 3:57 PM, Hannu Krosing ha...@2ndquadrant.com wrote:
On 02/25/2014 08:54 PM, Josh Berkus wrote:
That's called a straw man argument, Robert.
Me: We should recommend that people use jsonb unless they have a
specific reason for using json.
We could also make the opposite
On 02/26/2014 02:17 AM, Christophe Pettus wrote:
On Feb 25, 2014, at 1:57 PM, Hannu Krosing ha...@2ndquadrant.com wrote:
It is not in any specs, but nevertheless all major imlementations do it and
some code depends on it.
I have no doubt that some code depends on it, but all major
On 02/26/2014 07:02 AM, Merlin Moncure wrote:
On Tue, Feb 25, 2014 at 3:57 PM, Hannu Krosing ha...@2ndquadrant.com wrote:
It is not in any specs, but nevertheless all major imlementations do it and
some code depends on it.
IIRC, this behaviour is currently also met only by json and not by
On 02/25/2014 08:07 PM, Craig Ringer wrote:
On 02/26/2014 06:21 AM, Merlin Moncure wrote:
On Tue, Feb 25, 2014 at 4:03 PM, Josh Berkus j...@agliodbs.com wrote:
On 02/25/2014 12:12 PM, Robert Haas wrote:
I don't agree that jsonb should be preferred in all but a handful of
situations. Nor do I
On Wed, Feb 26, 2014 at 11:41 AM, Josh Berkus j...@agliodbs.com wrote:
On 02/26/2014 07:02 AM, Merlin Moncure wrote:
On Tue, Feb 25, 2014 at 3:57 PM, Hannu Krosing ha...@2ndquadrant.com wrote:
It is not in any specs, but nevertheless all major imlementations do it and
some code depends on it.
On 02/26/2014 09:57 AM, Merlin Moncure wrote:
On Wed, Feb 26, 2014 at 11:41 AM, Josh Berkus j...@agliodbs.com wrote:
On 02/26/2014 07:02 AM, Merlin Moncure wrote:
On Tue, Feb 25, 2014 at 3:57 PM, Hannu Krosing ha...@2ndquadrant.com
wrote:
It is not in any specs, but nevertheless all major
On Wed, Feb 26, 2014 at 12:05 PM, Josh Berkus j...@agliodbs.com wrote:
On 02/26/2014 09:57 AM, Merlin Moncure wrote:
What is not going to be so clear for users (particularly without good
supporting documentation) is how things break down in terms of usage
between hstore and jsonb.
On 02/26/2014 11:39 AM, Merlin Moncure wrote:
On Wed, Feb 26, 2014 at 12:05 PM, Josh Berkus j...@agliodbs.com wrote:
On 02/26/2014 09:57 AM, Merlin Moncure wrote:
What is not going to be so clear for users (particularly without good
supporting documentation) is how things break down in terms
On Wed, Feb 26, 2014 at 1:23 PM, Andrew Dunstan and...@dunslane.net wrote:
+ if (va-string.len == vb-string.len)
+ {
+ res = memcmp(va-string.val, vb-string.val,
va-string.len);
+ if (res == 0 arg)
+ *(bool *) arg = true;
On 02/26/2014 04:59 PM, Peter Geoghegan wrote:
On Wed, Feb 26, 2014 at 1:23 PM, Andrew Dunstan and...@dunslane.net wrote:
+ if (va-string.len == vb-string.len)
+ {
+ res = memcmp(va-string.val, vb-string.val,
va-string.len);
+ if (res == 0 arg)
+
On 2014-02-26 16:23:12 -0500, Andrew Dunstan wrote:
On 02/10/2014 09:11 PM, Andres Freund wrote:
Is it just me or is jsonapi.h not very well documented?
What about it do you think is missing? In any case, it's hardly relevant to
this patch, so I'll take that as obiter dicta.
It's
On Wed, February 26, 2014 23:10, Andrew Dunstan wrote:
new patch attached, change pushed to github.
[jsonb-13.patch.gz]
This does not apply, see attached: src/backend/utils/adt/jsonfuncs.c.rej
Please ignore if this was not supposed to work together with the earlier
nested-hstore-11.patch
On 02/26/2014 05:48 PM, Erik Rijkers wrote:
On Wed, February 26, 2014 23:10, Andrew Dunstan wrote:
new patch attached, change pushed to github.
[jsonb-13.patch.gz]
This does not apply, see attached: src/backend/utils/adt/jsonfuncs.c.rej
Please ignore if this was not supposed to work
On Wed, Feb 26, 2014 at 2:10 PM, Andrew Dunstan and...@dunslane.net wrote:
new patch attached, change pushed to github.
+ /* GUC variables */
+ static bool pretty_print_var = false;
+ #define SET_PRETTY_PRINT_VAR(x) ((pretty_print_var) ? \
+
Andres Freund wrote:
On 2014-02-26 16:23:12 -0500, Andrew Dunstan wrote:
+ if (va-string.len == vb-string.len)
+ {
+ res = memcmp(va-string.val, vb-string.val, va-string.len);
+ if (res == 0 arg)
+ *(bool *) arg = true;
Should be NULL, not 0.
No,
Peter Geoghegan wrote:
On Wed, Feb 26, 2014 at 2:10 PM, Andrew Dunstan and...@dunslane.net wrote:
new patch attached, change pushed to github.
+ /* GUC variables */
+ static bool pretty_print_var = false;
+ #define SET_PRETTY_PRINT_VAR(x) ((pretty_print_var) ? \
+
On Wed, Feb 26, 2014 at 5:06 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
I think that this is not a great idea. I think that we should do away
with the GUC, but keep the function hstore_print() so we can pretty
print that way. I don't believe that this falls afoul of the usual
obvious
On 02/26/2014 08:09 PM, Peter Geoghegan wrote:
On Wed, Feb 26, 2014 at 5:06 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
I think that this is not a great idea. I think that we should do away
with the GUC, but keep the function hstore_print() so we can pretty
print that way. I don't
On Wed, Feb 26, 2014 at 3:45 PM, Josh Berkus j...@agliodbs.com wrote:
On 02/26/2014 11:39 AM, Merlin Moncure wrote:
On Wed, Feb 26, 2014 at 12:05 PM, Josh Berkus j...@agliodbs.com wrote:
On 02/26/2014 09:57 AM, Merlin Moncure wrote:
What is not going to be so clear for users (particularly
On Wed, Feb 26, 2014 at 6:29 PM, Robert Haas robertmh...@gmail.com wrote:
Why can't this whole thing be shipped as an extension? It might well
be more convenient to have the whole thing packaged as an extension
than to have parts of it in core and parts of it not in core.
That's a good
On 02/26/2014 09:43 PM, Peter Geoghegan wrote:
On Wed, Feb 26, 2014 at 6:29 PM, Robert Haas robertmh...@gmail.com wrote:
Why can't this whole thing be shipped as an extension? It might well
be more convenient to have the whole thing packaged as an extension
than to have parts of it in core
* Andrew Dunstan (and...@dunslane.net) wrote:
The jsonb set will get larger as time goes on. I don't think either
of you are thinking very clearly about how we would do this.
Extensions can't call each other's code.
Yeah, that was puzzling me too.
Agree with the rest of your comments as well.
On 02/26/2014 07:41 PM, Josh Berkus wrote:
On 02/26/2014 07:02 AM, Merlin Moncure wrote:
On Tue, Feb 25, 2014 at 3:57 PM, Hannu Krosing ha...@2ndquadrant.com wrote:
It is not in any specs, but nevertheless all major imlementations do it and
some code depends on it.
IIRC, this behaviour is
On Mon, Feb 24, 2014 at 1:15 PM, Andrew Dunstan and...@dunslane.net wrote:
On 02/24/2014 11:06 AM, Merlin Moncure wrote:
On Mon, Feb 24, 2014 at 9:08 AM, Merlin Moncure mmonc...@gmail.com
wrote:
On Mon, Feb 24, 2014 at 8:46 AM, Merlin Moncure mmonc...@gmail.com
wrote:
I still find the
On Mon, Feb 24, 2014 at 12:31 PM, Josh Berkus j...@agliodbs.com wrote:
Aside from that, I want our docs to make a strong endorsement of using
jsonb over json for most users. jsonb will continue to be developed and
improved in the future; it is very unlikely that json will. Maybe
that's what
On 02/25/2014 08:13 AM, Robert Haas wrote:
I think you've got your head stuck deeply in the sand. The json data
type works exactly like the xml data type has always worked. There
have been occasional noises about making an xmlb data type, but
nobody's minded enough to do anything about it,
On Tue, Feb 25, 2014 at 09:38:50AM -0800, Josh Berkus wrote:
In short, I think you're viewing everything about jsonb with
rose-colored glasses on, and that your enthusiasm is mostly wishful
thinking. Will there be good things about jsonb? Of course. Will
lots of people want to use it
On Tue, Feb 25, 2014 at 12:38 PM, Josh Berkus j...@agliodbs.com wrote:
On 02/25/2014 08:13 AM, Robert Haas wrote:
I think you've got your head stuck deeply in the sand. The json data
type works exactly like the xml data type has always worked. There
have been occasional noises about making
On 02/25/2014 10:31 AM, Robert Haas wrote:
And I definitely don't
agree that our documentation should push people towards stuffing
everything in a JSON blob instead of using real column definitions.
Where did you get this out of my doc patch?
--
Josh Berkus
PostgreSQL Experts Inc.
On Tue, Feb 25, 2014 at 1:45 PM, Josh Berkus j...@agliodbs.com wrote:
On 02/25/2014 10:31 AM, Robert Haas wrote:
And I definitely don't
agree that our documentation should push people towards stuffing
everything in a JSON blob instead of using real column definitions.
Where did you
On 02/25/2014 10:50 AM, Robert Haas wrote:
On Tue, Feb 25, 2014 at 1:45 PM, Josh Berkus j...@agliodbs.com wrote:
On 02/25/2014 10:31 AM, Robert Haas wrote:
And I definitely don't
agree that our documentation should push people towards stuffing
everything in a JSON blob instead of using real
On 02/25/2014 09:45 AM, Bruce Momjian wrote:
It hurts our adoption substantially to confuse developers. We need to
recommend one type over the other, hence Use jsonb unless you need X.
Merlin is pushing the type of multivariable comparison where *I*
wouldn't be able to make sense of which
201 - 300 of 431 matches
Mail list logo
