Martijn van Oosterhout <kleptog@svana.org> writes:
> On Sat, Mar 04, 2006 at 01:16:55AM -0500, Tom Lane wrote:
>> What's bugging me about it is that the proposed syntax wedges a bunch
>> of index-access-method-specific parameters into what ought to be an
>> access-method-agnostic syntax; and furthermore does it by adding more
>> grammar keywords, something we have far too many of already.
> I think the current method is based on compatability with other
> databases. However, a more generic approach would be to (re)use the
> "definition" or "def_list" productions. This would allow any of the
> following (examples):
> CREATE INDEX foo ON bar (x) WITH (fillfactor = 70, option = blah);
> CREATE INDEX foo ON bar (x) WITH fillfactor = 70, option = blah;
> CREATE INDEX foo ON bar (x) (fillfactor = 70, option = blah);
> CREATE INDEX foo ON bar (x) fillfactor = 70, option = blah;
Yeah, something along this line is what I'd like to see; probably the
first form since that creates the least hazard of foreclosing other
additions to the syntax later. I'm not wedded to WITH as the keyword,
but I think there should be some keyword (ie not choice #3), and I
definitely want parens around the list else it has to be the last thing
in the command.
The main thing that would have to be resolved before you could proceed
very far with this is how does pg_dump extract the index's options?
My guess is that we'd want to extend pg_index entries to store the list
of options. This could probably be done in very much the same way that
ALTER USER SET or ALTER DATABASE SET GUC options are stored, ie, an
array containing name/value pairs.
Another point is that we should take some thought now for the prospect
that the set of options might change across time. I'd be inclined to
argue that if an unknown option appears in a CREATE INDEX command, it's
better to emit a warning and then drop the option, rather than error out
--- otherwise, reloading dumps into newer PG versions will be difficult.
This will impact the details of the index AM API, because the AM will
need a way to filter the options before they get stored in pg_index.
Possibly adding a "precheck" AM function call is the answer here.
Anyway the bottom line is that we need to put in some infrastructure
that can handle multiple index parameters, not a one-off solution that
only handles PCTFREE.
regards, tom lane