Re: attoptions

On Sun, Jan 17, 2010 at 9:57 PM, Alex Hunsaker <badalex(at)gmail(dot)com> wrote:
>>>> ... The idea that we want to support
>>>> attdistinct for system tables and index columns was based on a very
>>>> specific understanding of what that was going to do; for attoptions,
>>>> well, it might make sense for the options that we have now, but it
>>>> might not make sense for the next thing we want to add, and there's
>>>> not going to be any easy fix for that.
>
> Basically I was agreeing and saying when we add something new lets
> worry about it then.  Clearer?

It's clear now, but I don't think I agree. On balance, I'm inclined
to just rip out the special case permissions checks that
AT_SetDistinct uses and just use ATSimplePermissionsRelationOrIndex()
instead. 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.

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.

Does that make sense?

...Robert