Re: EXCEPT/INTERSECT for v6.4 - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: EXCEPT/INTERSECT for v6.4
Date
Msg-id 199901081627.LAA01207@candle.pha.pa.us
Whole thread Raw
List pgsql-hackers
I just received this via e-mail.  I am boucing the whole posting to the
patches list.  I am going to need help understanding the issues here.



> Hi!
> 
> INTERSECT and EXCEPT is available for postgresql-v6.4!
> 
> The patch against v6.4 is included at the end of the current text
> (in uuencoded form!)
> 
> I also included the text of my Master's Thesis. (a postscript
> version). I hope that you find something of it useful and would be
> happy if parts of it find their way into the PostgreSQL documentation
> project (If so, tell me, then I send the sources of the document!)
> 
> The contents of the document are:
>   -) The first chapter might be of less interest as it gives only an 
>      overview on SQL.
> 
>   -) The second chapter gives a description on much of PostgreSQL's
>      features (like user defined types etc. and how to use these features)
> 
>   -) The third chapter starts with an overview of PostgreSQL's internal
>      structure with focus on the stages a query has to pass (i.e. parser,
>      planner/optimizer, executor). Then a detailed description of the
>      implementation of the Having clause and the Intersect/Except logic is 
>      given.
> 
> Originally I worked on v6.3.2 but never found time enough to prepare
> and post a patch. Now I applied the changes to v6.4 to get Intersect
> and Except working with the new version. Chapter 3 of my documentation
> deals with the changes against v6.3.2, so keep that in mind when
> comparing the parts of the code printed there with the patched sources
> of v6.4.
> 
> Here are some remarks on the patch. There are some things that have
> still to be done but at the moment I don't have time to do them
> myself. (I'm doing my military service at the moment) Sorry for that
> :-(
> 
> -) I used a rewrite technique for the implementation of the Except/Intersect
>    logic which rewrites the query to a semantically equivalent query before
>    it is handed to the rewrite system (for views, rules etc.), planner, 
>    executor etc.
> 
> -) In v6.3.2 the types of the attributes of two select statements
>    connected by the UNION keyword had to match 100%. In v6.4 the types
>    only need to be familiar (i.e. int and float can be mixed). Since this
>    feature did not exist when I worked on Intersect/Except it 
>    does not work correctly for Except/Intersect queries WHEN USED IN
>    COMBINATION WITH UNIONS! (i.e. sometimes the wrong type is used for the 
>    resulting table. This is because until now the types of the attributes of 
>    the first select statement have been used for the resulting table. 
>    When Intersects and/or Excepts are used in combination with Unions it 
>    might happen, that the first select statement of the original query
>    appears at another position in the query which will be executed. The reason
>    for this is the technique used for the implementation of 
>    Except/Intersect which does a query rewrite!)
>    NOTE: It is NOT broken for pure UNION queries and pure INTERSECT/EXCEPT 
>          queries!!!
>    
> -) I had to add the field intersect_clause to some data structures 
>    but did not find time to implement printfuncs for the new field.
>    This does NOT break the debug modes but when an Except/Intersect
>    is used the query debug output will be the already rewritten query.
> 
> -) Massive changes to the grammar rules for SELECT and INSERT statements
>    have been necessary (see comments in gram.y and documentation for
>    deatails) in order to be able to use mixed queries like 
>    (SELECT ... UNION (SELECT ... EXCEPT SELECT)) INTERSECT SELECT...; 
> 
> -) When using UNION/EXCEPT/INTERSECT you will get:
>    NOTICE: equal: "Don't know if nodes of type xxx are equal".
>    I did not have  time to add comparsion support for all the needed nodes,
>    but the default behaviour of the function equal met my requirements.
>    I did not dare to supress this message!
> 
>    That's the reason why the regression test for union will fail: These
>    messages are also included in the union.out file!
> 
> -) Somebody of you changed the union_planner() function for v6.4
>    (I copied the targetlist to new_tlist and that was removed and
>    replaced by a cleanup of the original targetlist). These chnages
>    violated some having queries executed against views so I changed
>    it back again. I did not have time to examine the differences between the
>    two versions but now it works :-)
>    If you want to find out, try the file queries/view_having.sql on 
>    both versions and compare the results . Two queries won't produce a 
>    correct result with your version.
> 
> -) I included some queries in the patch (intersect.sql shows which 
>    Intersect/Except/Union queries are possible now!)
> 
>    Create a new database dummy and populate it:
> 
>    $ createdb dummy
>    $ psql dummy
>    dummy=> \i queries/create_insert.sql
>            .
>            .
>            .
>    dummy=> \i queries/intersect.sql
> 
> 
> So, that's it, hope my work will be useful!
> 
> regards
> 
>     Stefan


--  Bruce Momjian                        |  http://www.op.net/~candle maillist@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


pgsql-hackers by date:

Previous
From: Massimo Dal Zotto
Date:
Subject: bug in libpgtcl listen
Next
From: "Thomas G. Lockhart"
Date:
Subject: Re: [HACKERS] postgres and year 2000