On Tue, Dec 23, 2014 at 10:26 AM, Alvaro Herrera <alvhe...@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.gw28...@tamriel.snowman.net#20141016133218.gw28...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
