On 02/25/2014 10:54 AM, Josh Berkus wrote:
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
On Tue, Feb 25, 2014 at 1:54 PM, Josh Berkus j...@agliodbs.com wrote:
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
Josh Berkus escribió:
(to clarify below: json refers to the current varlena datatype; JSON
refers to JSON serialized data).
FWIW the term varlena json is misleading. jsonb is also varlena, only
different. I think you need a different term to say that json uses the
text representation.
--
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 agree that partisanship belongs in our
documentation. Therefore, -1 for your proposal to recommend that, and
+1 for Merlin's proposal to present a comparison
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 agree that partisanship belongs in our
documentation. Therefore, -1 for your proposal to
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 agree that partisanship belongs in our
On Tue, Feb 25, 2014 at 8:07 PM, Craig Ringer cr...@2ndquadrant.com wrote:
Please also highlight that any change will require a full table rewrite
with an exclusive lock, so data type choices on larger tables may be
hard to change later.
It sure looks like they're binary-coercible to me:
+
* Peter Geoghegan (p...@heroku.com) wrote:
On Tue, Feb 25, 2014 at 8:07 PM, Craig Ringer cr...@2ndquadrant.com wrote:
Please also highlight that any change will require a full table rewrite
with an exclusive lock, so data type choices on larger tables may be
hard to change later.
It sure
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 argument - people use json unless they
have a specific reason for using jsonb.
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 implementations
is too strong a statement. BSON, in
On 7.2.2014 00:47, Andrew Dunstan wrote:
On 02/05/2014 10:36 AM, Teodor Sigaev wrote:
Should I make new version of patch? Right now it's placed on github.
May be Andrew wants to change something?
Attached are updated patches.
Apart from the things Teodor has fixed, this includes
Yes, the repository you mentioned is the last version of our
development. It contains various fixes of issues by Andres, but we are
waiting Andrew, who is working on jsonb stuff.
On Mon, Feb 24, 2014 at 5:34 PM, Tomas Vondra t...@fuzzy.cz wrote:
On 7.2.2014 00:47, Andrew Dunstan wrote:
On
On Mon, Feb 24, 2014 at 12:20 AM, Josh Berkus j...@agliodbs.com wrote:
All,
Here's a draft cleanup on the JSON section of the Datatype docs. Since
there's been a bunch of incremental patches on this, I just did a diff
against HEAD.
I looked over json-functions a bit, but am not clear on
On Mon, Feb 24, 2014 at 8:46 AM, Merlin Moncure mmonc...@gmail.com wrote:
I still find the phrasing as jsonb is more efficient for most
purposes to be a bit off Basically, the text json type is faster for
serialization/deserialization pattern (not just document preservation)
and jsonb is
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 phrasing as jsonb is more efficient for most
purposes to be a bit off Basically, the text json type is faster for
On 02/24/2014 07:08 AM, Merlin Moncure wrote:
On Mon, Feb 24, 2014 at 8:46 AM, Merlin Moncure mmonc...@gmail.com wrote:
I still find the phrasing as jsonb is more efficient for most
purposes to be a bit off Basically, the text json type is faster for
serialization/deserialization pattern (not
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 phrasing as jsonb is more efficient for most
purposes to be a bit off Basically,
On 02/24/2014 02:15 PM, Andrew Dunstan wrote:
Having had my schedule very seriously disrupted by the storm in the US
South East a week or so ago, I am finally getting back to being able
to devote some time to jsonb. I hope to have new patches available
today or tomorrow at the latest.
Teodor, Oleg:
Some bitrot on the nested-hstore patch on current HEAD, possibly due to
the recent update release?
josh@radegast:~/git/pg94$ patch -p1 -i nested-hstore-10.patch
patching file contrib/hstore/.gitignore
patching file contrib/hstore/Makefile
patching file contrib/hstore/crc32.c
All,
Here's a draft cleanup on the JSON section of the Datatype docs. Since
there's been a bunch of incremental patches on this, I just did a diff
against HEAD.
I looked over json-functions a bit, but am not clear on what needs to
change there; the docs are pretty similar to other sections of
On Thu, Jan 30, 2014 at 11:07 AM, Andrew Dunstan and...@dunslane.net wrote:
Updated patches for both pieces. Included is some tidying done by Teodor,
and fixes for remaining whitespace issues. This now passes git diff --check
master cleanly for me.
So one thing that isn't clear from these
On 02/11/2014 01:16 AM, Merlin Moncure wrote:
On Mon, Feb 10, 2014 at 5:52 PM, Andres Freund and...@2ndquadrant.com wrote:
It works in enough cases atm that it's worthwile trying to keep it
working. Sure, it could be better, but it's what we have right now. Atm
it's e.g. the only realistic way
On Tue, Feb 11, 2014 at 3:35 AM, Hannu Krosing ha...@2ndquadrant.com wrote:
On 02/11/2014 01:16 AM, Merlin Moncure wrote:
On Mon, Feb 10, 2014 at 5:52 PM, Andres Freund and...@2ndquadrant.com
wrote:
It works in enough cases atm that it's worthwile trying to keep it
working. Sure, it could be
On 02/05/2014 06:48 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 02/05/2014 11:40 AM, Tom Lane wrote:
switching to binary is the same as text may well be the most prudent
path here.
If we do that we're going to have to live with that forever, aren't we?
Yeah, but the
Hi,
On 2014-02-06 18:47:31 -0500, Andrew Dunstan wrote:
* switching to using text representation in jsonb send/recv
+/*
+ * jsonb type recv function
+ *
+ * the type is sent as text in binary mode, so this is almost the same
+ * as the input function.
+ */
+Datum
On 02/10/2014 11:05 AM, Andres Freund wrote:
Hi,
On 2014-02-06 18:47:31 -0500, Andrew Dunstan wrote:
* switching to using text representation in jsonb send/recv
+/*
+ * jsonb type recv function
+ *
+ * the type is sent as text in binary mode, so this is almost the same
+ * as the input
On 02/10/2014 05:05 AM, Andres Freund wrote:
Hi,
On 2014-02-06 18:47:31 -0500, Andrew Dunstan wrote:
* switching to using text representation in jsonb send/recv
+/*
+ * jsonb type recv function
+ *
+ * the type is sent as text in binary mode, so this is almost the same
+ * as the input
On 2014-02-10 07:27:59 -0500, Andrew Dunstan wrote:
On 02/10/2014 05:05 AM, Andres Freund wrote:
I'd suggest making the format discernible from possible different future
formats, to allow introducing a proper binary at some later time. Maybe
just send a int8 first, containing the format.
On 02/10/2014 07:39 AM, Andres Freund wrote:
On 2014-02-10 07:27:59 -0500, Andrew Dunstan wrote:
On 02/10/2014 05:05 AM, Andres Freund wrote:
I'd suggest making the format discernible from possible different future
formats, to allow introducing a proper binary at some later time. Maybe
just
Craig Ringer cr...@2ndquadrant.com writes:
On 02/06/2014 01:48 AM, Tom Lane wrote:
switching to binary is the same as text may well be the most prudent
path here.
Can't we just reject attempts to transfer these via binary copy,
allowing only a text format? So rather than sending text when
On Mon, Feb 10, 2014 at 6:39 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-02-10 07:27:59 -0500, Andrew Dunstan wrote:
On 02/10/2014 05:05 AM, Andres Freund wrote:
I'd suggest making the format discernible from possible different future
formats, to allow introducing a proper binary
Merlin Moncure mmonc...@gmail.com writes:
On Mon, Feb 10, 2014 at 6:39 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-02-10 07:27:59 -0500, Andrew Dunstan wrote:
Teodor privately suggested something similar. I was thinking of just
sending a version byte, which for now would be
On Mon, Feb 10, 2014 at 12:15 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Merlin Moncure mmonc...@gmail.com writes:
On Mon, Feb 10, 2014 at 6:39 AM, Andres Freund and...@2ndquadrant.com
wrote:
On 2014-02-10 07:27:59 -0500, Andrew Dunstan wrote:
Teodor privately suggested something similar. I was
On 2014-02-10 11:59:53 -0600, Merlin Moncure wrote:
On Mon, Feb 10, 2014 at 6:39 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-02-10 07:27:59 -0500, Andrew Dunstan wrote:
On 02/10/2014 05:05 AM, Andres Freund wrote:
I'd suggest making the format discernible from possible different
On Mon, Feb 10, 2014 at 5:02 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-02-10 11:59:53 -0600, Merlin Moncure wrote:
On Mon, Feb 10, 2014 at 6:39 AM, Andres Freund and...@2ndquadrant.com
wrote:
On 2014-02-10 07:27:59 -0500, Andrew Dunstan wrote:
On 02/10/2014 05:05 AM, Andres
On 2014-02-10 17:35:12 -0600, Merlin Moncure wrote:
Wrong. You still need to have code that checks the server version and
see if it's supported (particularly for sending) and as there is *no
protocol negotiation of the formats at present it's all going to boil
down to if version = X do Y*.
On Mon, Feb 10, 2014 at 5:38 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-02-10 17:35:12 -0600, Merlin Moncure wrote:
Wrong. You still need to have code that checks the server version and
see if it's supported (particularly for sending) and as there is *no
protocol negotiation of
On 2014-02-10 17:48:32 -0600, Merlin Moncure wrote:
On Mon, Feb 10, 2014 at 5:38 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-02-10 17:35:12 -0600, Merlin Moncure wrote:
Wrong. You still need to have code that checks the server version and
see if it's supported (particularly for
On Mon, Feb 10, 2014 at 5:52 PM, Andres Freund and...@2ndquadrant.com wrote:
It works in enough cases atm that it's worthwile trying to keep it
working. Sure, it could be better, but it's what we have right now. Atm
it's e.g. the only realistic way to copy larger amounts of bytea between
On 2014-02-10 18:16:15 -0600, Merlin Moncure wrote:
On Mon, Feb 10, 2014 at 5:52 PM, Andres Freund and...@2ndquadrant.com wrote:
It works in enough cases atm that it's worthwile trying to keep it
working. Sure, it could be better, but it's what we have right now. Atm
it's e.g. the only
Merlin Moncure mmonc...@gmail.com writes:
right, json could be made work, but any other format change introduced
to any other already existing type will break. That's not a real
solution unless we decree henceforth that no formats will change from
here on in, in which case I withdraw my
On Mon, Feb 10, 2014 at 6:24 PM, Andres Freund and...@2ndquadrant.com wrote:
And if we add a new format version in 9.5 we need to make it discernible
from the 9.4 format. Without space for a format indicator we'd have to
resort to ugly tricks like defining the high bit in the first byte set
Merlin Moncure mmonc...@gmail.com writes:
On Mon, Feb 10, 2014 at 6:24 PM, Andres Freund and...@2ndquadrant.com wrote:
And if we add a new format version in 9.5 we need to make it discernible
from the 9.4 format. Without space for a format indicator we'd have to
resort to ugly tricks like
On Mon, Feb 10, 2014 at 6:39 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Merlin Moncure mmonc...@gmail.com writes:
On Mon, Feb 10, 2014 at 6:24 PM, Andres Freund and...@2ndquadrant.com
wrote:
And if we add a new format version in 9.5 we need to make it discernible
from the 9.4 format. Without
On 2014-02-10 19:01:48 -0600, Merlin Moncure wrote:
On Mon, Feb 10, 2014 at 6:39 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Merlin Moncure mmonc...@gmail.com writes:
On Mon, Feb 10, 2014 at 6:24 PM, Andres Freund and...@2ndquadrant.com
wrote:
And if we add a new format version in 9.5 we need
On 10 February 2014 20:11, Hannu Krosing ha...@krosing.net wrote:
The fastest and lowest parsing cost format for JSON is tnetstrings
http://tnetstrings.org/ why not use it as the binary wire format ?
It would be as binary as it gets and still be generally parse-able by
lots of different
On Monday, February 10, 2014, Andres Freund and...@2ndquadrant.com wrote:
On 2014-02-10 19:01:48 -0600, Merlin Moncure wrote:
On Mon, Feb 10, 2014 at 6:39 PM, Tom Lane t...@sss.pgh.pa.usjavascript:;
wrote:
Merlin Moncure mmonc...@gmail.com javascript:; writes:
On Mon, Feb 10, 2014 at
Hi,
Is it just me or is jsonapi.h not very well documented?
On 2014-02-06 18:47:31 -0500, Andrew Dunstan wrote:
+/*
+ * for jsonb we always want the de-escaped value - that's what's in token
+ */
+static void
+jsonb_in_scalar(void *state, char *token, JsonTokenType tokentype)
+{
+
On 02/10/2014 08:50 PM, Tom Dunstan wrote:
On 10 February 2014 20:11, Hannu Krosing ha...@krosing.net wrote:
The fastest and lowest parsing cost format for JSON is tnetstrings
http://tnetstrings.org/ why not use it as the binary wire format ?
It would be as binary as it gets and still be
On 02/10/2014 09:11 PM, Andres Freund wrote:
diff --git a/src/backend/utils/adt/jsonfuncs.c
b/src/backend/utils/adt/jsonfuncs.c
index e1d8aae..50ddf50 100644
--- a/src/backend/utils/adt/jsonfuncs.c
+++ b/src/backend/utils/adt/jsonfuncs.c
there's lots of whitespace/tab damage in this file.
On 2014-02-10 22:15:21 -0500, Andrew Dunstan wrote:
On 02/10/2014 09:11 PM, Andres Freund wrote:
diff --git a/src/backend/utils/adt/jsonfuncs.c
b/src/backend/utils/adt/jsonfuncs.c
index e1d8aae..50ddf50 100644
--- a/src/backend/utils/adt/jsonfuncs.c
+++ b/src/backend/utils/adt/jsonfuncs.c
On Fri, February 7, 2014 00:47, Andrew Dunstan wrote:
Attached are updated patches.
jsonb-10.patch.gz
nested-hstore-10.patch.gz
Small changes to json documentation, mostly of typo caliber.
Thanks,
Erik Rijkers
--- doc/src/sgml/datatype.sgml.orig 2014-02-09 14:27:55.264512678 +0100
+++
On 02/06/2014 01:48 AM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 02/05/2014 11:40 AM, Tom Lane wrote:
switching to binary is the same as text may well be the most prudent
path here.
If we do that we're going to have to live with that forever, aren't we?
Yeah, but
On 02/01/2014 05:20 PM, Andres Freund wrote:
diff --git a/src/backend/utils/adt/Makefile b/src/backend/utils/adt/Makefile
index 1ae9fa0..fd93d9b 100644
--- a/src/backend/utils/adt/Makefile
+++ b/src/backend/utils/adt/Makefile
@@ -32,7 +32,8 @@ OBJS = acl.o arrayfuncs.o array_selfuncs.o
Andrew Dunstan and...@dunslane.net writes:
On 02/01/2014 05:20 PM, Andres Freund wrote:
Odd, most OBJS lines are kept in alphabetical order, but that doesn't
seem to be the case here.
This whole list is a mess, and we don't even have all the range_types
files following each other.
Worth
Andrew Dunstan wrote:
This whole list is a mess, and we don't even have all the
range_types files following each other.
Worth cleaning up?
I'm actually wondering if it might be worth having some subgroups of
object files and then combining them into $OBJS.
Doesn't the MSVC build stuff
On 02/06/2014 11:38 AM, Alvaro Herrera wrote:
Andrew Dunstan wrote:
This whole list is a mess, and we don't even have all the
range_types files following each other.
Worth cleaning up?
I'm actually wondering if it might be worth having some subgroups of
object files and then combining them
On Feb 5, 2014, at 3:59 PM, Andrew Dunstan and...@dunslane.net wrote:
I got a slightly earlier start ;-) For people wanting to play along, here's
what this change looks like:
https://github.com/feodor/postgres/commit/3fe899b3d7e8f806b14878da4a4e2331b0eb58e8
Man I love seeing all that read.
On Fri, Feb 7, 2014 at 1:18 AM, Andrew Dunstan and...@dunslane.net wrote:
On 02/01/2014 05:20 PM, Andres Freund wrote:
diff --git a/src/backend/utils/adt/Makefile
b/src/backend/utils/adt/Makefile
index 1ae9fa0..fd93d9b 100644
--- a/src/backend/utils/adt/Makefile
+++
+static void
+recvJsonbValue(StringInfo buf, JsonbValue *v, uint32 level, int c)
+ v-size = sizeof(JEntry) * 2 + VARSIZE_ANY(v-numeric);
What's the *2 here?
Reservation for aligment. It's allowed to be v-size greater than it's actually
needed. Fixed.
This function and
On Wed, Feb 5, 2014 at 12:44 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
send/recv functions are also needed for binary-format COPY. IMHO jsonb must
have send/recv functions. All other built-in types have them, except for
types like 'smgr', 'aclitem' and 'any*' that no-one should be
On 02/05/2014 10:48 AM, Merlin Moncure wrote:
On Wed, Feb 5, 2014 at 12:44 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
send/recv functions are also needed for binary-format COPY. IMHO jsonb must
have send/recv functions. All other built-in types have them, except for
types like
On 02/05/2014 10:36 AM, Teodor Sigaev wrote:
+Datum
+jsonb_typeof(PG_FUNCTION_ARGS)
+{
...
+}
Hm, shouldn't that be in jsonfuncs.c?
No idea, i don't have an objection
No it shouldn't. The json equivalent function is in json.c, and needs to
be because it uses the parser internals
On Wed, Feb 5, 2014 at 10:22 AM, Andrew Dunstan and...@dunslane.net wrote:
I'm actually surprised we have an alternate binary wire format for
jsonb at all; json is explicitly text and I'm not sure what the use
case of sending the internal structure is. Meaning, maybe jsonb
send/recv should be
Merlin Moncure mmonc...@gmail.com writes:
On Wed, Feb 5, 2014 at 10:22 AM, Andrew Dunstan and...@dunslane.net wrote:
The whole reason we have jsonb is to avoid reparsing where possible
Sure; but on the server side. The wire format is for handling client
concerns. For example, the case
On 02/05/2014 11:40 AM, Tom Lane wrote:
Merlin Moncure mmonc...@gmail.com writes:
On Wed, Feb 5, 2014 at 10:22 AM, Andrew Dunstan and...@dunslane.net wrote:
The whole reason we have jsonb is to avoid reparsing where possible
Sure; but on the server side. The wire format is for handling
Andrew Dunstan and...@dunslane.net writes:
On 02/05/2014 11:40 AM, Tom Lane wrote:
switching to binary is the same as text may well be the most prudent
path here.
If we do that we're going to have to live with that forever, aren't we?
Yeah, but the other side of that coin is that we'll have
On 02/05/2014 12:48 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 02/05/2014 11:40 AM, Tom Lane wrote:
switching to binary is the same as text may well be the most prudent
path here.
If we do that we're going to have to live with that forever, aren't we?
Yeah, but the
On Wed, Feb 5, 2014 at 11:48 AM, Tom Lane t...@sss.pgh.pa.us wrote:
If we had infinite time/manpower, this wouldn't really be an issue.
We don't, though, and so I suggest that this may be one of the better
things to toss overboard.
The hstore send/recv functions have basically the same
On 02/05/2014 07:48 AM, Merlin Moncure wrote:
Another point I'm struggling with is
what jsonb brings to the table that isn't covered either hstore or
json; working through a couple of cases I find myself not using the
jsonb functionality except as a 'hstore json formatter' which the json
type
On 02/05/2014 02:03 PM, Josh Berkus wrote:
Frankly, if it were entirely up to me HSTORE2 would be part of core and
its only interface would be JSONB. But it's not. So this is a compromise.
You could only do that by inventing a new type. But hstore2 isn't a new
type, it's meant to be the
On Wed, Feb 5, 2014 at 1:03 PM, Josh Berkus j...@agliodbs.com wrote:
On 02/05/2014 07:48 AM, Merlin Moncure wrote:
Another point I'm struggling with is
what jsonb brings to the table that isn't covered either hstore or
json; working through a couple of cases I find myself not using the
jsonb
On 02/05/2014 03:15 PM, Merlin Moncure wrote:
On Wed, Feb 5, 2014 at 1:03 PM, Josh Berkus j...@agliodbs.com wrote:
On 02/05/2014 07:48 AM, Merlin Moncure wrote:
Another point I'm struggling with is
what jsonb brings to the table that isn't covered either hstore or
json; working through a
On Wed, Feb 5, 2014 at 2:37 PM, Andrew Dunstan and...@dunslane.net wrote:
The time for this discussion was months ago. I would not have spent many
many hours of my time if I thought it was going to be thrown away. I find
this attitude puzzling, to say the least. You were a major part of the
On 02/05/2014 03:45 PM, Merlin Moncure wrote:
On Wed, Feb 5, 2014 at 2:37 PM, Andrew Dunstan and...@dunslane.net wrote:
The time for this discussion was months ago. I would not have spent many
many hours of my time if I thought it was going to be thrown away. I find
this attitude puzzling, to
Merlin,
Not following this. I do not see how the presence of jsonb helps at
all. Client to server communication will be text-binary (and vice
versa) and handling within the server itself will be in binary. This
is the crux of my point.
Except that handling it on the server, in binary,
On Wed, Feb 5, 2014 at 3:03 PM, Josh Berkus j...@agliodbs.com wrote:
That was the original goal. However, Oleg and Teodor's late delivery of
Hstore2 limited what Andrew could do for JSONB before CF4 started.
yeah. anyways, I'm good on this point.
merlin
--
Sent via pgsql-hackers mailing
On 02/05/2014 04:06 PM, Merlin Moncure wrote:
On Wed, Feb 5, 2014 at 3:03 PM, Josh Berkus j...@agliodbs.com wrote:
That was the original goal. However, Oleg and Teodor's late delivery of
Hstore2 limited what Andrew could do for JSONB before CF4 started.
I also had issues. But this is the
On 02/05/2014 01:10 PM, Andrew Dunstan wrote:
On 02/05/2014 12:48 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 02/05/2014 11:40 AM, Tom Lane wrote:
switching to binary is the same as text may well be the most prudent
path here.
If we do that we're going to have to live
On 02/03/2014 07:27 AM, Andres Freund wrote:
On 2014-02-03 09:22:52 -0600, Merlin Moncure wrote:
I lost my stomach (or maybe it was the glass of red) somewhere in the
middle, but I think this needs a lot of work. Especially the io code
doesn't seem ready to me. I'd consider ripping out the
On 02/03/2014 05:22 PM, Merlin Moncure wrote:
I lost my stomach (or maybe it was the glass of red) somewhere in the
middle, but I think this needs a lot of work. Especially the io code
doesn't seem ready to me. I'd consider ripping out the send/recv code
for 9.4, that seems the biggest can of
Andrew provided us more information and we'll work on recv. What
people think about testing this stuff ? btw, we don't have any
regression test on this.
Oleg
On Wed, Feb 5, 2014 at 2:03 AM, Josh Berkus j...@agliodbs.com wrote:
On 02/03/2014 07:27 AM, Andres Freund wrote:
On 2014-02-03
On Sat, Feb 1, 2014 at 4:20 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-01-30 14:07:42 -0500, Andrew Dunstan wrote:
+ para id=functions-json-table
+ xref linkend=functions-json-creation-table shows the functions that
are
+ available for creating typejson/type values.
+
On 2014-02-03 09:22:52 -0600, Merlin Moncure wrote:
I lost my stomach (or maybe it was the glass of red) somewhere in the
middle, but I think this needs a lot of work. Especially the io code
doesn't seem ready to me. I'd consider ripping out the send/recv code
for 9.4, that seems the
On 2014-01-30 14:07:42 -0500, Andrew Dunstan wrote:
+ para id=functions-json-table
+ xref linkend=functions-json-creation-table shows the functions that
are
+ available for creating typejson/type values.
+ (see xref linkend=datatype-json)
/para
- table id=functions-json-table
On 02/01/2014 05:20 PM, Andres Freund wrote:
[Long review]
Most of these comments actually refer to Teodor and Oleg's code.
I will attend to the parts that apply to my code.
Thanks for the review.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
Hi,
On 2014-02-01 18:13:42 -0500, Andrew Dunstan wrote:
[Long review]
Most of these comments actually refer to Teodor and Oleg's code.
I will attend to the parts that apply to my code.
Well, somebody will need to address them nonetheless :/
Greetings,
Andres Freund
--
Andres Freund
On 02/01/2014 06:15 PM, Andres Freund wrote:
Hi,
On 2014-02-01 18:13:42 -0500, Andrew Dunstan wrote:
[Long review]
Most of these comments actually refer to Teodor and Oleg's code.
I will attend to the parts that apply to my code.
Well, somebody will need to address them nonetheless :/
Hmm,
neither me, nor Teodor have experience and knowledge with
populate_record() and moreover hstore here is virgin and we don't know
the right behaviour, so I think we better take it from jsonb, once
Andrew realize it. Andrew ?
On Fri, Jan 31, 2014 at 4:52 AM, Andrew Dunstan and...@dunslane.net
On Fri, Jan 31, 2014 at 4:03 AM, Oleg Bartunov obartu...@gmail.com wrote:
Hmm,
neither me, nor Teodor have experience and knowledge with
populate_record() and moreover hstore here is virgin and we don't know
the right behaviour, so I think we better take it from jsonb, once
Andrew realize it.
On 01/31/2014 08:57 AM, Merlin Moncure wrote:
On Fri, Jan 31, 2014 at 4:03 AM, Oleg Bartunov obartu...@gmail.com wrote:
Hmm,
neither me, nor Teodor have experience and knowledge with
populate_record() and moreover hstore here is virgin and we don't know
the right behaviour, so I think we
On Fri, Jan 31, 2014 at 8:45 AM, Andrew Dunstan and...@dunslane.net wrote:
On 01/31/2014 08:57 AM, Merlin Moncure wrote:
On Fri, Jan 31, 2014 at 4:03 AM, Oleg Bartunov obartu...@gmail.com
wrote:
Hmm,
neither me, nor Teodor have experience and knowledge with
populate_record() and moreover
On 01/31/2014 09:53 AM, Merlin Moncure wrote:
On Fri, Jan 31, 2014 at 8:45 AM, Andrew Dunstan and...@dunslane.net wrote:
On 01/31/2014 08:57 AM, Merlin Moncure wrote:
On Fri, Jan 31, 2014 at 4:03 AM, Oleg Bartunov obartu...@gmail.com
wrote:
Hmm,
neither me, nor Teodor have experience and
On Fri, Jan 31, 2014 at 9:26 AM, Andrew Dunstan and...@dunslane.net wrote:
On 01/31/2014 09:53 AM, Merlin Moncure wrote:
On Fri, Jan 31, 2014 at 8:45 AM, Andrew Dunstan and...@dunslane.net
wrote:
On 01/31/2014 08:57 AM, Merlin Moncure wrote:
On Fri, Jan 31, 2014 at 4:03 AM, Oleg Bartunov
On 01/31/2014 02:48 PM, Merlin Moncure wrote:
Actually, there is a workaround to the limitations of hstore(record):
yeah I'm ok with hstore() function as it is. That also eliminates
backwards compatibility concerns so things worked out. The only 'must
fix' 9.4 facing issue I see on the
On 01/31/2014 11:35 PM, Andrew Dunstan wrote:
Yes, or anyone else who wants to join in. I'd very much welcome a
substantial code review - I have been staring at this far too long on
my own.
I should mention that in fact by far the largest piece of this is not my
work, but Oleg and
ok, great. This is really fabulous. So far most everything feels
natural and good.
I see something odd in terms of the jsonb use case coverage. One of
the major headaches with json deserialization presently is that
there's no easy way to easily move a complex (record- or array-
containing)
On Thu, Jan 30, 2014 at 9:50 AM, Andrew Dunstan and...@dunslane.net wrote:
Now, if we're agreed on that, I then also wonder if the 'as_text'
argument needs to exist at all for the populate functions except for
backwards compatibility on the json side (not jsonb). For non-complex
structures it
On 01/30/2014 12:34 PM, Merlin Moncure wrote:
On Thu, Jan 30, 2014 at 9:50 AM, Andrew Dunstan and...@dunslane.net wrote:
Now, if we're agreed on that, I then also wonder if the 'as_text'
argument needs to exist at all for the populate functions except for
backwards compatibility on the json
On 01/30/2014 06:45 PM, Andrew Dunstan wrote:
On 01/30/2014 12:34 PM, Merlin Moncure wrote:
On Thu, Jan 30, 2014 at 9:50 AM, Andrew Dunstan and...@dunslane.net
wrote:
Now, if we're agreed on that, I then also wonder if the 'as_text'
argument needs to exist at all for the populate functions
301 - 400 of 431 matches
Mail list logo
