On Tue, Dec 23, 2014 at 10:26 AM, Alvaro Herrera <[email protected]> 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/[email protected]#[email protected] > > 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 ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
