Re: Multi-column distinctness.

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