> > Here are the proposals for solutioning the "Return proper effected
> > tuple count from complex commands [return]" issue as seen on TODO.
> >
> > Any comments ?... This is obviously open to voting and discussion.
>
> We don't have a whole lot of freedom in this; this area is
> covered by the
> SQL standard. The major premise in the standard's point of
> view is that
> views are supposed to be transparent. That is, if
>
> SELECT * FROM my_view WHERE condition;
>
> return N rows, then a subsequently executed
>
> UPDATE my_view SET ... WHERE condition;
>
> returns an update count of N, no matter what happens behind the scenes. I
> don't think this matches Tom Lane's view exactly, but it's a lot closer
> than your proposal.
Yes, exactly. I think it does match Tom's proposal as best we can. But we need a
knowing dba that creates correct rules. Since you can create a lot more powerful
views in pg than usual, I guess that is not such a farfetched demand.
I do not know whether above extends to inserts ? In Informix you can
create views "WITH CHECK OPTION", then inserted and updated rows are guaranteed to
still be visible by the view. If you don't add that clause, inserts and updates
may produce rows that are not visible through the view. The affected row count still
includes those though.
Andreas
