Re: contribute pg_get_viewdef2 et al

> -----Original Message-----
> From: Andreas Pflug [mailto:Andreas(dot)Pflug(at)web(dot)de]
> Sent: 07 May 2003 14:07
> To: Dave Page; pgadmin-hackers(at)postgresql(dot)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