Re: Does Type Have = Operator?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Does Type Have = Operator?
Дата
Msg-id 5609.1463079754@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Does Type Have = Operator?  ("David E. Wheeler" <david@justatheory.com>)
Ответы Re: Does Type Have = Operator?  ("David E. Wheeler" <david@justatheory.com>)
Re: Does Type Have = Operator?  (Andrew Dunstan <andrew@dunslane.net>)
Список pgsql-hackers
"David E. Wheeler" <david@justatheory.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
thefirst 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 =
operatorin core. But now what we have JSONB, perhaps it makes sense to finally take sides and intoduce JSON = that does
plaintext 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 ...
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Use %u to print user mapping's umid and userid
Следующее
От: Fabien COELHO
Дата:
Сообщение: Re: Perf Benchmarking and regression.