On Wed, May 21, 2008 at 7:56 AM, Hannu Krosing <[EMAIL PROTECTED]> wrote: > On Wed, 2008-05-21 at 10:40 +0200, Andreas Pflug wrote: >> Florian Pflug wrote: >> > >> > But maybe you could store the whitespace appearing before (or after?) >> > a token in the parse tree that is stored for a view. That might not >> > allow reconstructing the *precise* statement, but at least the >> > reconstructed statement would preserve newlines and indention - which >> > probably is the whole reason for wanting to store the original >> > statement in the first place, no? I >> >> >> Not the whole reason. To get a view definition that is more readable, >> the pretty_bool option of pg_get_viewdef already does some newline and >> indent formatting. Not the initial formatting, but Good Enough (TM), I >> believe. >> >> What's really lost is any comment that might have existed in the initial >> source. I previously had the idea to invent comment nodes, but never >> came to implement them. > > Is'nt a view roughly equivalent to a SQL language FUNCTION with no > arguments and a single select. > > If it is so, then I can't see, why we can store the source for functions > but not for VIEWs
That's what I'm saying. The behavior is a little different however. If you rename a column from under a function it will fail the next time the plan is generated while a view will track the column name in terms of how the view is defined to the backend. In other words, you can leave the function body alone because changing a column underlying a function has no side affects on the function body itself. It is blindly reapplied by the backend each time it's parsed and planned. So in a sense the function body stored in prosrc will never diverge from the parsed function since the parsed version is temporary. Views are different. They are parsed and the parsed version is stored in permanent fashion. Your comments would be right on the money if the view was re-parsed in each session...for things to work that way we would have to give up rename tracking of views. For the record, I think function behavior is better (i.e. not automatic name tracking on rename). In my ideal world, if I make alter table DDL, I would prefer to have all dependent objects recheck their source sql vs. the database and alert me of errors. This seems a better way to double check for dba mistakes although column rename can become a pain. However, I add columns, etc to tables _much_ more frequently than I rename them. merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
