On Thu, Apr 26, 2012 at 9:12 PM, Tom Lane wrote:
> I wrote:
>> Ryan Kelly 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
On Sat, Apr 28, 2012 at 17:20, Ryan Kelly 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 have warnings o
On Fri, Apr 27, 2012 at 10:22:11AM -0400, Tom Lane wrote:
> Ryan Kelly 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 y
Ryan Kelly 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.
> I've attached
On Fri, Apr 27, 2012 at 11:27:03AM +0200, Vik Reykja wrote:
> On Fri, Apr 27, 2012 at 03:12, Tom Lane 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. (not
On Fri, Apr 27, 2012 at 03:12, Tom Lane 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)
> And should
I wrote:
> Ryan Kelly 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 empty-string v
Ryan Kelly 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
> --
>
