Re: [PATCH] Erase the distinctClause if the result is unique by definition

Поиск
Список
Период
Сортировка
От Andy Fan
Тема Re: [PATCH] Erase the distinctClause if the result is unique by definition
Дата
Msg-id CAKU4AWqd==QOP=caLNb5FrDZtD_tpMku3NYuc8HtYsBEgtgg7Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PATCH] Erase the distinctClause if the result is unique bydefinition  (Julien Rouhaud <rjuju123@gmail.com>)
Список pgsql-hackers
On Thu, Feb 13, 2020 at 5:39 PM Julien Rouhaud <rjuju123@gmail.com> wrote:
On Tue, Feb 11, 2020 at 10:06:17PM +0530, Ashutosh Bapat wrote:
> On Tue, Feb 11, 2020 at 8:27 AM Andy Fan <zhihui.fan1213@gmail.com> wrote:
>
> > On Tue, Feb 11, 2020 at 12:22 AM Ashutosh Bapat <
> > ashutosh.bapat.oss@gmail.com> wrote:
> >
> >>>
> >>> [PATCH] Erase the distinctClause if the result is unique by
> >>>  definition
> >>
> >> I forgot to mention this in the last round of comments. Your patch was
> >> actually removing distictClause from the Query structure. Please avoid
> >> doing that. If you remove it, you are also removing the evidence that this
> >> Query had a DISTINCT clause in it.
> >
> > Yes, I removed it because it is the easiest way to do it.  what is the
> > purpose of keeping the evidence?
> >
>
> Julien's example provides an explanation for this. The Query structure is
> serialised into a view definition. Removing distinctClause from there means
> that the view will never try to produce unique results.

And also I think that this approach will have a lot of other unexpected side
effects.  Isn't changing the Query going to affect pg_stat_statements queryid
computing for instance?

Thanks,  the 2 factors above are pretty valuable.  so erasing the 
distinctClause is not reasonable,  I will try another way. 

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Antonin Houska
Дата:
Сообщение: Dead code in adminpack
Следующее
От: Fujii Masao
Дата:
Сообщение: Re: table partitioning and access privileges