Zeugswetter Andreas OSB sIT <andreas.zeugswet...@s-itsolutions.at> writes:
>> Which leads me to the same conclusion: anything as complicated as CASE
>> is the wrong design. But perhaps for slightly different reasons.
> What I like about the sql CASE is, that it is expression based, and thus
> allows full flexibility in partitioning and is highly self documenting.
> Do we need to invent special syntax, or could we use common syntax and
> detect specific use cases and handle them specially ?
The problem with that approach is you still need to have an
implementation for the non-specific cases. What I want is to design
the syntax so that *only* the optimized special cases are possible.
We should not waste time either on implementing the general case or
on constantly re-deducing which special case applies. That's the
Achilles heel of what we have now (ie, constraint exclusion via theorem
proving) --- it's a beautifully general approach, but it's so general
that it's hard to make any but the simplest cases work efficiently, and
the runtime cost of proving *each time* that a special case applies is
horrid.
The KISS principle applies with a vengeance here. I think we should
make the partitioning stuff handle only the simplest cases but do those
well. Anybody who wants something more complex can still try to tackle
it via the existing facilities.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
