Skip site navigation (1) Skip section navigation (2)

Re: Re: logical changeset generation v3 - comparison to Postgres-R change set format

From: Hannu Krosing <hannu(at)2ndQuadrant(dot)com>
To: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
Cc: Noah Misch <noah(at)leadboat(dot)com>, Markus Wanner <markus(at)bluegap(dot)ch>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Re: logical changeset generation v3 - comparison to Postgres-R change set format
Date: 2013-01-14 08:51:01
Message-ID: 50F3C6F5.30404@2ndQuadrant.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On 01/13/2013 08:06 PM, Dimitri Fontaine wrote:
> Hannu Krosing <hannu(at)2ndQuadrant(dot)com> writes:
>>> Does this hint that postgreSQL also needs an sameness operator
>>> ( "is" or "===" in same languages).
>> How do people feel about adding a real sameness operator ?
> Well. I would prefer it if we can bypass the need for it.
What is actually sufficient for current problem is sameness
which compares outputs of type output functions and also
considers NULLs to be the same.

The reason for not providing equality for xml was not that two xml
files which compare equal as text could be considered unequal in
any sense but that there are some other textual representations
of the same xml which could also be considered to be equal, like
  different whitespace between tag and attribute
> Then Do we need the full range of eq, eql, equal and equalp predicates,
> and would all of them allow overriding or just some?
I consider sameness as basic thing as IS NULL, so the sameness
should not be overridable. Extending IS NOT DISTINCT FROM to
do this comparison instead of current '=' seems reasonable.

That is

SELECT '<tag/>'::xml IS DISTINCT FROM '<tag />'::xml

should return TRUE as long as the internal representation of the
two differ and even after you add equality operator to xml
which compares some canonic form of xml and thus would make

SELECT '<tag/>'::xml = '<tag />'::xml ;

be TRUE.


Regards,
Hannu

>
>    http://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node74.html
>
> Regards,



In response to

pgsql-hackers by date

Next:From: Markus WannerDate: 2013-01-14 09:03:48
Subject: Re: Re: logical changeset generation v3 - comparison to Postgres-R change set format
Previous:From: 李海龙Date: 2013-01-14 07:18:18
Subject: Re: I s this a bug of spgist index in a heavy write condition?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group