On Tue, Dec 29, 2009 at 9:12 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> Yep. It would also lower the barrier to future innovations of that >> type, which would be a good thing, IMO. Unfortunately we'd likely >> need to continue to support the existing syntax at least for >> attstattarget, which is kind of a bummer, but seems managable. I >> think we could throw over the syntax for ALTER TABLE ... ADD >> STATISTICS DISTINCT since it is an 8.5-ism. > > Yeah --- if we think we might want to do this, now is the time, > before we're stuck with supporting that syntax. (I was thinking > earlier today that attdistinct was already in 8.4, but it's not.)
I am just starting to look at this now. One of the questions I have is what we should call the options. We could call the regular options something like "ndistinct" or "distinct", but I'm not too sure what to call the "for-inheritance-trees" version of that. I suppose we could just use the familiar "inh" prefix and call it "inhndistinct", but that looks suspiciously like gobbledygook. Someone's understanding of just what that is supposed to mean might be a little... indistinct (ba dum). Another option would be to call it "inherits_ndistinct", or something like that, which seems a little more readable, but not great: I don't think there's going to be any getting around the need to RTFM before setting these parameters. In terms of syntax, I'm thinking something like: ALTER TABLE name ALTER COLUMN column SET ( column_parameter = value [, ...] ) I am also very tempted before beginning this work to rename reloptions.c to options.c or genoptions.c or somesuch. If we're going to use it for relations, attributes, and tablespaces, chances are good we're going to use it for other things, too. The FDW stuff is already borrowing from it as well. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers