On 5/11/16 7:05 PM, David E. Wheeler wrote:
On May 11, 2016, at 10:34 AM, Kevin Grittner <kgri...@gmail.com> wrote:

I'm not clear enough on your intended usage to know whether these
operators are a good fit, but they are sitting there waiting to be
used if they do fit.

Huh. I haven’t had any problems with IS DISTINCT FROM for rows, except for the 
situation in which a failure is thrown because the types vary, say between TEXT 
and CITEXT. That can drive the tester crazy, since it says something like:

    Results differ beginning at row 3:
        have: (44,Anna)
        want: (44,Anna)

But overall I think that’s okay; the tester really does want to make sure the 
type is correct.

Speaking specifically to is(), what I'd find most useful is if it at least hinted that there might be some type shenanigans going on, because I've run across something like your example more than once and it always takes a lot to finally figure out WTF is going on.

I think it'd also be useful to be able to specify an equality operator to is(), though that means not using IS DISTINCT.

Something else to keep in mind here is that is() is defined as is(anyelement, anyelement, text), which means you've lost your original type information when you use it. I don't think you could actually do anything useful here because of that.
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)   mobile: 512-569-9461

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to