On Tue, Dec 23, 2014 at 10:26 AM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
> Tom Lane wrote:
>> Again, I suppose I should have objected earlier, but I really seriously
>> doubt that this is a good idea.
>
> Ugh. I thought we had a consensus that this was the accepted way
> forward; that's my reading of the old thread,
>
http://www.postgresql.org/message-id/flat/20141016133218.GW28859@tamriel.snowman.net#20141016133218.GW28859@tamriel.snowman.net
>
> Breaking clients was considered acceptable, which is why some of these
> functions were introduced. There were some differing opinions; Simon
> for instance suggested the use of an array rather than a bitmask, but
> that would have broken clients all the same.
>
> If there's strong opposition to this whole line of development, I can
> revert. Anyone else wants to give an opinion?
I would have preferred (and I believe argued for) keeping the existing
catalog representation for existing attributes and using a bitmask for
new ones, to avoid breaking client code. But I am not sure if that's
actually the best decision. I find Tom's concern about needing more
than 64 attributes to be ill-founded; I can't really see that
happening on any timescale that matters.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
