On 5/11/16 7:05 PM, David E. Wheeler wrote:
> On May 11, 2016, at 10:34 AM, Kevin Grittner <kgrittn@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
becausethe 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