> 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
No comments:
Post a Comment