On Wed, Apr 4, 2012 at 12:51 PM, Thomas Kellerer <spam_eater@gmx.net> wrote:
> Jon Nelson wrote on 04.04.2012 19:47:
>
>>> What about a set-returning function that builds the query dynamically and
>>> wrapping that into a view?
>>>
>>> That way the view would never change and client would still have the
>>> perspective of a view/table
>>>
>>> Your function could pick up the changes automatically e.g. by looking at
>>> information_schema.tables
>>
>>
>> That sounds pretty cool, but that is beyond my understanding.
>> I can write a set-returning function easily enough (call it
>> build_the_huge_table for "clarity"), but the "wrap that into a view"
>> part throws me.
>> Could you give me an example?
>
>
> create view the_huge_table
> as
> select *
> from build_the_huge_table()
I gave it a try but the query planner doesn't elide unnecessary tables
(those for which the condition will never be true), the way using the
current view does.
Given the relatively small price in storage (5% or so) to add the
appropriate column to the data, and the advantages of table
inheritance, I think that'll be the way for me to go (if I make any
change at all).
Thanks, all!
--
Jon
