From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | Jon Nelson <jnelson+pgsql(at)jamponi(dot)net> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: views, queries, and locks |
Date: | 2012-04-04 17:50:57 |
Message-ID: | CAHyXU0yVruQG0ZoCuM9U+aHTRkd2XfuU4=xK2dqJputQ+ThZuA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Wed, Apr 4, 2012 at 12:47 PM, Jon Nelson <jnelson+pgsql(at)jamponi(dot)net> wrote:
> On Wed, Apr 4, 2012 at 11:22 AM, Thomas Kellerer <spam_eater(at)gmx(dot)net> wrote:
>> Jon Nelson wrote on 04.04.2012 15:50:
>>
>>> I need to have something table-like from the client's perspective for
>>> a bunch of reasons.
>>> For now, assume that I want to keep using the view and that I'd like
>>> to find better ways to address my concerns.
>>
>>
>> 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?
it's trivial:
create view stuff as select * from function();
it's less trivial if you need to pass arguments to the function, but
can be doable depending.
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Kellerer | 2012-04-04 17:51:34 | Re: views, queries, and locks |
Previous Message | Jon Nelson | 2012-04-04 17:47:12 | Re: views, queries, and locks |