On Wed, Aug 26, 2009 at 7:47 PM, Andrew Dunstan<and...@dunslane.net> wrote: >> Did we kill the idea of trying to retain the original view definition? >> Granted, that doesn't really help for SELECT *... > > That has nothing at all to do with the issue. The question is not about > whether to keep the original, it's about how to format the reconstructed > query.
I suspect Jim's thinking that if we keep the original we don't have to reconstruct the query ever. Unfortunately cases like "select *" -- and that's not the only case, think of columns that have been renamed -- throw a wrench in the works for that. I agree with Tom's concerns -- think of that guy who was bumping up against the 1600 column limit. At least if they're on one line you can still see the structure of the query albeit with a very very wide scrollbar... But for typical queries I do agree one per line is better. That is actually how I format my queries when they have complex expressions in the target list. Perhaps formatting one per line whenever there's an alias or the value is a complex expression but putting any unaliased columns (such as produced by select *) in a single line would be a good compromise? Incidentally, how does your patch format a complex subquery in the target list? but I think on balance this is probably better. In the extreme think of that guy a few days ago who was bumping up against the 1600 column limit. Assuming he had a few layers of nested subqueries his -- greg http://mit.edu/~gsstark/resume.pdf -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
