Re: Multi-column distinctness.
| От | Tomas Vondra |
|---|---|
| Тема | Re: Multi-column distinctness. |
| Дата | |
| Msg-id | 56268656.1040208@2ndquadrant.com обсуждение исходный текст |
| Ответ на | Re: Multi-column distinctness. (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: Multi-column distinctness.
|
| Список | pgsql-hackers |
On 10/20/2015 05:59 PM, Tom Lane wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Tue, Oct 20, 2015 at 10:51 AM, Tomas Vondra >> <tomas.vondra@2ndquadrant.com> wrote: >>>>> ISTM that we could use COLLECT STATISTICS instead of ADD STATISTICS, and >>>>> use REMOVE STATISTICS instead of DROP STATISTICS. That way we can use >>>>> ALTER TABLE rather than inventing a new command. 5 minute change... > >>> That seems like a neat idea, actually. I'm not sure COLLECT is a good choice >>> as it suggest the statistics is actually built, but that only happens during >>> ANALYZE. But otherwise this seems to solve the issues with keywords and it's >>> quite simple. > >> But ADD is no better there. I think ALTER TABLE .. COLLECT STATISTICS >> isn't any worse than ALTER TABLE ... CLUSTER ON index_name. In both >> cases, it means, when you do this operation, do it this way. > >> I would suggest that instead of DROP or REMOVE, the opposite should be >> ALTER TABLE .. NO COLLECT STATISTICS. > > Why is this an improvement over using already-existing keywords? The problem is that the actual syntax is ADD [COLUMN], so we can't simply use ADD STATISTICS as that would mean a conflict in the grammar. Resolving it means either making COLUMN non-optional, or adding STATISTICS to reserved keywords - both options break existing code. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: