On Thu, Apr 26, 2012 at 9:12 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
Ryan Kelly rpkell...@gmail.com writes:
In my mind, all of these should have been rejected as erroneous input.
To that end, I have attached a patch which causes all of these inputs
to be rejected as invalid.
Hm, I
On Fri, Apr 27, 2012 at 10:22:11AM -0400, Tom Lane wrote:
Ryan Kelly rpkell...@gmail.com writes:
As long as we make it consistent on both sides of the '=' (and document
it, too), then I don't really care either way. Currently you have to use
quotes to get an empty key, so I thought it
On Sat, Apr 28, 2012 at 17:20, Ryan Kelly rpkell...@gmail.com wrote:
I don't think any language supports the empty key edge case in this way.
The only language I know of that will let you get away with it is Perl,
and in that case you get undef, not the empty string, and it's a warning
if you
On Fri, Apr 27, 2012 at 03:12, Tom Lane t...@sss.pgh.pa.us wrote:
Does anybody else have an opinion as to which of these solutions is
more preferable?
I think all unquoted whitespace should be ignored, so I prefer your
solution. (note: I haven't actually tested it, I'm going off these emails)
On Fri, Apr 27, 2012 at 11:27:03AM +0200, Vik Reykja wrote:
On Fri, Apr 27, 2012 at 03:12, Tom Lane t...@sss.pgh.pa.us wrote:
Does anybody else have an opinion as to which of these solutions is
more preferable?
I think all unquoted whitespace should be ignored, so I prefer your
Ryan Kelly rpkell...@gmail.com writes:
As long as we make it consistent on both sides of the '=' (and document
it, too), then I don't really care either way. Currently you have to use
quotes to get an empty key, so I thought it natural to that you should
have to quote to get an empty value.
Ryan Kelly rpkell...@gmail.com writes:
It seems that the hstore parser has some odd behavior in the the
handling of certain malformed input constructions:
[db] select 'a=,b=1'::hstore;
hstore
--
a=,b=1
[db] select 'a= ,b=1'::hstore;
hstore
--
I wrote:
Ryan Kelly rpkell...@gmail.com writes:
In my mind, all of these should have been rejected as erroneous input.
To that end, I have attached a patch which causes all of these inputs
to be rejected as invalid.
Hm, I would have expected all three of these to result in a having
an
