On Tue, Jan 13, 2015 at 10:56:48AM -0500, Peter Eisentraut wrote:
On 11/30/14 11:45 AM, Tom Lane wrote:
The API break isn't a big issue imo. The net effect would be that eg
hstore 9.3.6 wouldn't work against a 9.3.5 server. We do that sort of
thing *all the time* --- at least twice in the
On 1/15/15 2:29 PM, Bruce Momjian wrote:
On Tue, Jan 13, 2015 at 10:56:48AM -0500, Peter Eisentraut wrote:
On 11/30/14 11:45 AM, Tom Lane wrote:
The API break isn't a big issue imo. The net effect would be that eg
hstore 9.3.6 wouldn't work against a 9.3.5 server. We do that sort of
thing
On 11/30/14 11:45 AM, Tom Lane wrote:
The API break isn't a big issue imo. The net effect would be that eg
hstore 9.3.6 wouldn't work against a 9.3.5 server. We do that sort of
thing *all the time* --- at least twice in the past year, according to
a quick scan of the commit logs. If you
On 11/26/2014 11:48 AM, Andrew Dunstan wrote:
On 11/26/2014 11:19 AM, Tom Lane wrote:
bo...@edookit.com writes:
The hstore_to_json_loose(hstore) produces an invalid JSON in the
following
case:
SELECT hstore_to_json_loose(hstore(ARRAY ['name'], ARRAY ['1.'] :: TEXT
[]))
Output: {name: 1.}
Andrew Dunstan and...@dunslane.net writes:
what do you want to do about this? In the back branches, exposing a
function like this would be an API change, wouldn't it? Perhaps there we
just need to pick up the 100 lines or so involved from json.c and copy
them into hstore_io.c, suitably
On 11/30/2014 11:45 AM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
what do you want to do about this? In the back branches, exposing a
function like this would be an API change, wouldn't it? Perhaps there we
just need to pick up the 100 lines or so involved from json.c and copy
Andrew Dunstan and...@dunslane.net writes:
OK, here's the patch.
Can we make IsValidJsonNumber() take a const char *? Also its
comment should specify that it doesn't require nul-terminated
input, if indeed it doesn't. Otherwise +1.
regards, tom lane
--
Sent via
On 11/30/2014 04:31 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
OK, here's the patch.
Can we make IsValidJsonNumber() take a const char *? Also its
comment should specify that it doesn't require nul-terminated
input, if indeed it doesn't. Otherwise +1.
bo...@edookit.com writes:
The hstore_to_json_loose(hstore) produces an invalid JSON in the following
case:
SELECT hstore_to_json_loose(hstore(ARRAY ['name'], ARRAY ['1.'] :: TEXT
[]))
Output: {name: 1.}
The actual output is indeed incorrect as JSON does not permit `1.` - it must
be a
On 11/26/2014 11:19 AM, Tom Lane wrote:
bo...@edookit.com writes:
The hstore_to_json_loose(hstore) produces an invalid JSON in the following
case:
SELECT hstore_to_json_loose(hstore(ARRAY ['name'], ARRAY ['1.'] :: TEXT
[]))
Output: {name: 1.}
The actual output is indeed incorrect as JSON does
On 11/26/2014 11:48 AM, Andrew Dunstan wrote:
In json.c we now check numbers like this:
JsonLexContext dummy_lex;
boolnumeric_error;
...
dummy_lex.input = *outputstr == '-' ? outputstr + 1 : outputstr;
dummy_lex.input_length = strlen(dummy_lex.input);
11 matches
Mail list logo
