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 o
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 twic
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 yo
On 11/30/2014 04:31 PM, Tom Lane wrote:
Andrew Dunstan 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.
Then I h
Andrew Dunstan 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 pgsql-hackers mailing
On 11/30/2014 11:45 AM, Tom Lane wrote:
Andrew Dunstan 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
Andrew Dunstan 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 modified. In the dev
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.}
T
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);
json_lex_numb
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
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
>
11 matches
Mail list logo
