Re: Functional dependencies and GROUP BY

Поиск
Список
Период
Сортировка
От Dean Rasheed
Тема Re: Functional dependencies and GROUP BY
Дата
Msg-id AANLkTimD391VDSxg+9rddc6KqciortxLqP4XJVfBi_Ju@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Functional dependencies and GROUP BY  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Functional dependencies and GROUP BY  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 7 August 2010 03:51, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
>> Next version.  Changed dependencies to pg_constraint, removed handling
>> of unique constraints for now, and made some enhancements so that views
>> track dependencies on constraints even in subqueries.  Should be close
>> to final now. :-)
>
> I've committed this with some revisions, notably:
>
> The view.c changes were fundamentally wrong.  The right place to
> extract dependencies from a parsetree is in dependency.c, specifically
> find_expr_references_walker.  The way you were doing it meant that
> dependencies on constraints would only be noticed for views, not for
> other cases such as stored plans.
>
> I rewrote the catalog search to look only at pg_constraint, not using
> pg_index at all.  I think this will be easier to extend to the case of
> looking for UNIQUE + NOT NULL, whenever we get around to doing that.
> I also moved the search into catalog/pg_constraint.c, because it didn't
> seem to belong in parse_agg (as hinted by the large number of #include
> additions you had to make to put it there).
>
> I put in a bit of caching logic to prevent repeating the search for
> multiple Vars of the same relation.  Tests or no tests, I can't believe
> that's going to be cheap enough that we want to repeat it over and
> over...
>
>                        regards, tom lane
>

I was testing out this feature this morning and discovered that the
results may be non-deterministic if the PK is deferrable. I think that
check_functional_grouping() should exclude any deferrable constraints,
since in general, any inference based on a deferrable constraint can't
be trusted when planning a query, since the constraint can't be
guaranteed to be valid when the query is executed. That's also
consistent with the SQL spec.

The original version of the patch had that check in it, but it
vanished from the final committed version. Was that just an oversight,
or an intentional change?

Regards,
Dean


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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: lexing small ints as int2
Следующее
От: Tom Lane
Дата:
Сообщение: Re: ps buffer is incorrectly padded on the (latest) OS X