> -----Original Message-----
> From: Andreas Pflug [mailto:Andreas.Pflug@web.de]
> Sent: 07 May 2003 14:07
> To: Dave Page; pgadmin-hackers@postgresql.org
> Subject: Re: contribute pg_get_viewdef2 et al
>
>
> Dave Page wrote:
> >I agree your example is, umm, icky, but can you prove that
> your patch
> >will not misintepret anything and produce bad output? Once
> again, isn't
> >this a case of playing it safe?
> >
> How should I do this? How to PROVE software? The old problem.
Well, yes :-)
> You can have a look at the code, and say if there's a case when the
> isSimpleNode function will falsely return true; in this case a wrong
> query might be created. This function is intentionally made
> VERY simple,
> so it shouldn't be too much work. I've sent this Tom, but he didn't
> manage to have a look at it, I think.
I agree it looks pretty straightforward and simple. Try sending it to
the hackers list though - I'll bet Tom gets loads of personally
addressed queries and email everyday, and if he's like me gives
preference to those that used the lists.
> Right, that's why this only works if the backend stores the query at
> the moment it creates the plan.
Yeah, but it doesn't work. Consider:
CREATE TABLE foo (bar int4);
CREATE VIEW foo_view AS
SELECT
bar
FROM
foo
WHERE
bar > 100;
<store view def>
ALTER TABLE foo ALTER COLUMN bar RENAME TO sheep;
At this point the stored view definition is no longer valid.
> It's absolutely no option to
> stick users
> to a single creation interface to have the query saved as
> side-effect;
> this must be implemented integrally in the backend.
Absolutely. Of course, Jean-Michel's code had very different intentions
for which such a mechanism was more appropriate.
Regards, Dave
