Re: POSS. FEATURE REQ: "Dynamic" Views - Mailing list pgsql-general

From Chris Travers
Subject Re: POSS. FEATURE REQ: "Dynamic" Views
Date
Msg-id 43109DBD.1080705@travelamericas.com
Whole thread Raw
In response to Re: POSS. FEATURE REQ: "Dynamic" Views  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
Tom Lane wrote:

>
>
>But why exactly is this a good idea?
>
Especially since it seems one could write PLPGSQL functions to emulate
this if it was so important.  The lack of PLPGSQL functions to do this
seems to indicate that it is not worth the trouble,

>It is oft-repeated advice that you don't use
>"SELECT *" ever in production programming, because your applications
>will break as soon as any columns are added (or removed, even if they
>don't make any use of those columns).
>
With all due respect, I often use SELECT * in production programming
becuase the languages I write in allow me to return the results as a
hash table.  In this case, things only break if you delete a needed
column, and added columns have no real effect unless they are of
substantial size (but this is a separate issue).  With a good RAD
environment (such as Python, Perl, or PHP), I don't think that SELECT *
is unduly dangerous.

>  The proposed dynamic view
>facility would move that instability of results right into the views.
>
>
Again, this would not be *that* hard to do with PLPGSQL and a function
like redefine_view(name, text) which would store the definitions of the
views in a temporary table, and then rebuild dependant views.  Again the
fact that it is not commonly done indicates simply that there is no need.

Best Wishes,
Chris Travers
Metatron Technology Consulting

pgsql-general by date:

Previous
From: Douglas McNaught
Date:
Subject: Re: A strange problem
Next
From: Chris Travers
Date:
Subject: Re: Postgresql replication