On Mon, Jun 2, 2014 at 2:47 PM, Tom Lane <tgl@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
