Re: Having Patch (against v6.3.2)

I have applied this fine patch from Stephan.

It fixes many problems with Having, and some other problems that exist.

Vadim, can you check on the psort_end() issue, and see where that should
go. I am lost in that area.

[Charset ISO-8859-1 unsupported, filtering to ASCII...]
> Hi out there!
>
> I think I have good news for you: Having is working now! The patch is
> included in this email (tarred, gnu-zipped and finally uuencoded).
>
> But before you go on unpacking the patch let me tell you about the
> following items:
>
> 1) Queries using the having clause on base tables should work well
> now. Here some tested features, (examples included in the patch):
>
> 1.1) Subselects in the having clause
> 1.2) Double nested subselects
> 1.3) Subselects used in the where clause and in the having clause
> simultaneously
> 1.4) Union Selects using having
> 1.5) Indexes on the base relations are used correctly
> 1.6) Unallowed Queries are prevented (e.g. qualifications in the
> having clause that belong to the where clause)
> 1.7) Insert into as select
>
> 2) Queries using the having clause on view relations also work
> but there are some restrictions:
>
> 2.1) Create View as Select ... Having ...; using base tables in the select
> does work *BUT*: only simple queries are allowed to this new
> created view. This is *not* because of the having
> logic but on the technique used to implement
> views in postgreSQL, the query rewrite system.
>
> 2.1.1) The Query rewrite system:
> As you know, postgreSQL uses a query rewrite system to
> implement views. It does so by storing the query used to define
> the view somewhere in the system catalogs. If a user makes a
> query against the view the system "rewrites" the user query by
> merging it with the stored query (used to define the view). The
> new "rewritten" query is optimized, planned, etc and executed
> against the base tables from the view definition query.
>
> 2.1.2) Why are only simple queries allowed against a view from 2.1) ?
> The problem with the technique described in 2.1.1) is, that it
> is unfortunately not possible to merge any two SQL queries in
> in such a way that the result will behave as expected:
> consider the following view definition:
>
> create view testview as
> select pid, sid
> from part
> where pid=5
> group by pid;
>
> and the following query:
>
> select max(pid), sid
> from testview
> where sid = 100
> group by sid;
>
> The query rewrite system will produce something like:
>
> select max(pid), sid
> from part
> where pid=5 AND sid = 100 /* no problem here */
> group by ??? /* which attribute(s) to group by?? */
>
> You see, if the view definition and the query both contain
> a group clause, we will run into troubles.
>
> The solution to this would be the implementation of subselects
> in the from clause, then the rewrite system would produce:
>
> select max(pid), sid
> from (select pid, sid
> from part
> where pid=5
> group by pid)
> where sid = 100
> group by sid;
>
> 2.2) Select ... from testview1, testview2, ... having...;
> does also work, as long as the views used are simple
> row/column subsets of the baserelations used. (No group clauses
> in the view definitons)
>
>
> 3) Bug in ExecMergeJoin ??
> This is something that has *NOTHING* to do with the Having logic!
> Proof: Try the following query (without having my patch applied):
>
> select s.sid, s.sname, s.city
> from supplier s
> where s.sid+10 in (select se1.pid
> from supplier s1, sells se1, part p1
> where s1.sid=se1.sid and
> s1.sname=s.sname and
> se1.pid=p1.pid);
>
> (The file 'queries/create_insert.sql' included in the patch contains the
> data for this, the query is included in 'queries/having.sql' !)
>
> As you can see, there is neither a having qual nor an aggregate
> function used in the above query an you will see, it will fail!
>
> I found out that the reason for this is in the function
> 'ExecMergeJoin()' in
> switch (mergestate->mj_JoinState)
> {
> ....
> case EXEC_MJ_NEXTOUTER:
> ....
> CleanUpSort(node->join.lefttree->lefttree);
> CleanUpSort(node->join.righttree->lefttree);
> ....
> }
>
> In 'CleanUpSort()' the function 'psort_end()' gets called and
> closes down the sort, which is correct as long as no subselects
> are in use!
>
> I found out, that the bug does not appear when I comment the call
> to 'psort_end()' out in 'CleanUpSort()'.
>
> I heavily tested the system after that and things worked well but
> maybe this is just a lucky chance.
>
> So please, if anybody who has good knowledge of that part of the
> code could have a look at that it would be great!
>
> I am sure the sort has to be ended at some time calling 'psort_end()'
> but I did not have enough time to look for the right place. I was
> just happy about the fact it produced some correct results and
> stopped working on that.
>
>
> 4) Test Examples included:
> in the patch there is a directory 'queries' containing the
> following files:
> create_insert.sql to create the test relations and views
> destroy.sql to drop the test relations and views
> having.sql the test queries on base relations
> view_having.sql the test queries on / defining views
>
> 5) The patch is against the original v6.3.2 and can be applied
> by:
> cd ..../postgresql-6.3.2/
> patch [-p2] < having_6.3.2.diff
>
>
>
>
> Regards Stefan

--
Bruce Momjian | 830 Blythe Avenue
maillist(at)candle(dot)pha(dot)pa(dot)us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)