From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "David E(dot) Wheeler" <david(at)justatheory(dot)com> |
Cc: | fabriziomello(at)gmail(dot)com, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Does Type Have = Operator? |
Date: | 2016-05-13 01:43:04 |
Message-ID: | 57353128.1050704@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 05/12/2016 03:02 PM, Tom Lane wrote:
> "David E. Wheeler" <david(at)justatheory(dot)com> writes:
>> Some might argue that it ought to compare JSON objects, effectively be the equivalent of ::jsonb = ::jsonb, rather than ::text = ::text. But as Andrew points out to me offlist, “if that's what they want why aren't they using jsonb in the first place?â€
>> So I think that, up to the introduction of JSONB, it was important not to side one way or the other and put a JSON = operator in core. But now what we have JSONB, perhaps it makes sense to finally take sides and intoduce JSON = that does plain text comparison. Thoughts?
> Meh. Right now, if you want to compare values of type JSON, you have to
> either cast them to text or to jsonb, and that effectively declares which
> comparison semantics you want. I'm not sure that prejudging that is a
> good thing for us to do, especially when the argument that text semantics
> are what you would probably want is so weak.
>
> Andrew mentions in the extension you pointed to that providing a default
> comparison operator would enable people to do UNION, DISTINCT, etc on JSON
> columns without thinking about it. I'm not convinced that "without
> thinking about it" is a good thing here. But if we were going to enable
> that, I'd feel better about making it default to jsonb semantics ...
>
I think you've been a little liberal with quoting the docs ;-) The
reason I made it an extension is precisely because it's not
unambiguously clear what json equality should mean.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2016-05-13 03:09:29 | Re: Keeping CURRENT_DATE and similar constructs in original format |
Previous Message | Tom Lane | 2016-05-13 00:09:24 | Re: Keeping CURRENT_DATE and similar constructs in original format |