Hello, > > 5) syntax > > --------- > > The syntax might be one of the pain points if we eventually decide to > commit the multivariate stats patch. I have no intention in blocking this > patch for that reasons, but if we might design the syntax to make it > compatible with the multivariate patch, that'd be nice. But it seems to me > the syntax is pretty much the same, no? > > > > I.e. it uses > > > > ADD STATISTICS (options) ON (columns) > > > > just like the multivariate patch, no? Well, it doesn't really check the > stattypes in ATExecAddDropMvStatistics except for checking there's a single > entry, but the syntax seems OK. > > > BTW mixing ADD and DROP in ATExecAddDropMvStatistics seems a bit > confusing. Maybe two separate methods would be better?
No problem. > BTW one more comment about the syntax - you ran into the same conflict > between "ADD [COLUMN] column" and "ADD STATISTICS" like I did, but you > solved it by making the COLUMN required while I made STATISTICS keyword. > I'm not enthusiastic about the keyword thing, I don't have firm idea that it has the priority than duplication of syntax, but I followed the policy to reduce keywords. Which do you think is more acceptable between the additional definition caused by new keywords and syntax splitting caused by avoiding them for this case? > but making the COLUMN > required is certainly much worse as it breaks many existing scripts. The > keyword inky breaks cases that manipulate "statistics" column. Ouch! It is simply by accident, or my lack of carefulness. I will come up with fixed syntax later.. > If any of this is unacceptable, then we probably need to come up with a > different syntax. regards, -- Kyotaro Horiguchi NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers