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
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 |