Re: Re: Abbreviated keys for Datum tuplesort

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Peter Geoghegan <pg(at)heroku(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:17:18
Message-ID: 20150403121718.GD3663@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> I'm about as much
> of a stickler for the details as you will find on this mailing list,
> or possibly, in the observable universe,

This made me laugh. :)

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

Thanks!

Stephen

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2015-04-03 12:18:58 Re: Re: Abbreviated keys for Datum tuplesort
Previous Message Peter Geoghegan 2015-04-03 12:12:18 Re: Re: Abbreviated keys for Datum tuplesort