Re: attoptions

On Tue, Jan 19, 2010 at 07:49, Robert Haas <robertmhaas(at)gmail(dot)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.