On Tue, Jan 19, 2010 at 07:49, Robert Haas <robertmh...@gmail.com> wrote: >That will mean that users can't use ALTER TABLE ... ALTER > COLUMN ... SET STATISTICS DISTINCT for system tables, but I don't > think that's much of a loss, and it certainly seems cleaner than > hoping that any additional attoptions we add in the future will be > things that we don't mind having applied to system tables.
I assumed there was a good reason to apply them to system tables. But I admit I did not follow the original SET STATISTICS DISTINCT patch. [ looks ] Oh ok seeing that you were the original patch author you probably have a good idea about the above, so ill defer :) > There's a further design issue here in that the reloptions code > currently contemplates at most 31 types of objects. That makes sense > if the object types are things like "table" or "GIN index", but it's > not going to work if we get too fine-grained. The "right" way to make > n_distinct apply to both table columns and index columns and > n_distinct_inherited only to table columns is probably to define two > different reloption kinds, but that's burning up our supply of > available bits a little more quickly than I feel comfortable with. So > I'm inclined to just let n_distinct_inherited be applied either place, > and if you happen to apply it to an index column it just won't affect > anything. We might want to refactor the reloptions API in the future > to allow this to be handled better, but I don't think we need or want > to do that for 8.5. Agreed. Although ISTM we might be able to extend it just using two bits: RELOPT_KIND_SYSTEM RELOPT_KIND_INHERIT #define RELOPT_KIND_INDEX RELOPT_KIND_BTREE|RELOPT_KIND_GIST|... Abuse ? Maybe. The hardest part I think would be setting those flags appropriately. But yes, lets keep it simple for now. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
