On Mon, Jun 2, 2014 at 2:47 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> Deparse-and-reparse might be better, but I'll bet that has too >> many problems to be viable, too (even if I haven't yet thought of what >> they are). For better or for worse, I think the best we're likely to >> be able to do is somehow manipulate the already-parsed rewrite rule. >> I don't have any great ideas about how to do that, either, but it >> seems less problematic than going back to the SQL representation. > > I think deparse-and-reparse is exactly what we have to do, mainly because, > if you subscribe to the idea that the user should see and approve semantic > changes, what else are we going to show her except SQL? If she wants to > adjust the changes, it's even less plausible that the working > representation is not SQL text. We might well produce the initial draft > form by manipulating the parsed querytree before deparsing, though.
So I think the scenario we're talking about, simplified down to basics, is something like this: CREATE TABLE foo (a int); CREATE VIEW bar AS SELECT a FROM foo; ALTER TABLE foo ALTER COLUMN a SET DATA TYPE bigint; If we wanted to make that last statement succeed instead of failing, what would we want it to do? I can see two answers. Answer #1 is that the column type of bar.a changes from int to bigint and the view definition is still SELECT a FROM foo. In that case, showing the user the SQL does not help them see and approve semantic changes because the SQL is completely unchanged. Answer #2 is that the column type of bar.a remains int4 and therefore the view definition mutates to something like SELECT a::int4 AS a FROM foo. In that case, showing the user the SQL does help the user understand what is happening ... but, as you say, you'd probably generate the new parse tree by manipulating the existing stored rule. And if you then deparsed it, how would that help? It's not like you can dump out the revised view definition and let the user edit it and put it back in. The view has to get modified as part of the same action as changing the table's column type, or you can't do anything we can't do already. Frankly, I don't think showing that particular thing to the user is necessary anyway; it's not like the semantics of pushing a cast on top of every use of the column within a related view are particularly hard to understand. And, anyway, whatever we do here has to be simple to invoke or we lose most of the advantage. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
