On Sun, Aug 19, 2012 at 8:14 AM, Dmitriy Igrishin <dmit...@gmail.com> wrote: >> For various reasons, this often goes the wrong way. Views are often >> the right way to go. +1 on your comment above -- the right way to do >> views (and SQL in general) is to organize scripts and to try and avoid >> managing everything through GUI tools. It works. > > The drawback of this approach is that in some cases we need a > factory function(s) (in terms of the OOP) which returns one or a > set of objects (i.e. the function returns the view type). But since > the views are not in the dump we are forced to abandon this solution > and go with workarounds (such as creating extra composite types > to use as returning values or use the tables).
Could you elaborate on this? > PS. I'm tried to found a SQL formatter for format views definitions > stored in the database, but unsuccessful. Even if you could find one, I wouldn't use it: the database changes the structure of you query. Suppose you had: CREATE VIEW v AS SELECT *, a*b AS product FROM foo; The database converts that to: CREATE VIEW v AS SELECT a,b, a*b AS product FROM foo; That means that if you add columns after the fact, the view definition in the database will diverge from what the source would create. Besides that, there are a number of other things that the database does like add unnecessary casts, column aliases and parentheses that make a purely textual solution impossible. merlin -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
