Re: Re: Abbreviated keys for Datum tuplesort

From: Peter Geoghegan <pg(at)heroku(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: Abbreviated keys for Datum tuplesort
Date: 2015-04-03 12:18:58
Message-ID: CAM3SWZQed=3ACzG6FP9yyoA=Licsx74-AzMONPAaLR_=vmPYUQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Apr 3, 2015 at 1:17 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
>> but even I'm not willing to
>> expend the amount of ink and emotional energy you have on whether a
>> variable that holds +1, 0, or -1 ought to be declared as "int" or
>> "int32". Does it matter? Yeah. Is it worth this much argument? No.
>
> My only comment will be on this very minor aspect (and I'm quite
> agnostic as to what is decided, particularly as I haven't read the patch
> at all), but, should we consider an enum (generically) for such cases?
> If that's truly the extent of possible values, and anything else is an
> error, then at least if I was writing DDL to support this, I'd use an
> enum, maybe a domain, or a CHECK constraint (though I'd likely feel
> better about the enum or domain approach).

It isn't the case that an enum can support it. Some comparators will
return -5 rather than -1 (as with C-style comparators in general,
sometimes comparisons can be implemented using subtraction and things
like that).

--
Peter Geoghegan

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Korotkov 2015-04-03 12:23:51 Re: Cube extension kNN support
Previous Message Stephen Frost 2015-04-03 12:17:18 Re: Re: Abbreviated keys for Datum tuplesort