Thread

1. Open 6.3 issues

   Bruce Momjian <maillist@candle.pha.pa.us> — 1998-02-23T13:39:08Z

   Here is the newest list:
   
   ---------------------------------------------------------------------------
   
   test new view permission code, install new pg_user view for use with \d
   max tuple size patch(Darren)
   Self-join optimizer performance problem
   Get interfaces fixed for new protocol
   Profiling improvements?
   Problem with tables >2Gb, add elog()?
   Do we want to add timestamps to elog messages?
   ScanKeyData missing initializations
   Alpha/64-bit issues, mkoidname() problem
   'Can not write block blind' error on createdb and regression collision(Vadim)
   Views on aggregates fail
   large objects memory exhaustion
   Commit sgml document sources(Thomas)
   Commit html documents(Thomas)
   Commit postscript documents(Thomas)
   Fix isinf.c irix port problem reported by Andrew(Marc)
   Check select_views regression test
   REVOKE ALL ON pg_user FROM PUBLIC crashes if run many times, cache issue(Jan)
   
   
   -- 
   Bruce Momjian
   maillist@candle.pha.pa.us
   
   

2. Re: [HACKERS] Open 6.3 issues

   Jan Wieck <jwieck@debis.com> — 1998-02-23T17:08:14Z

   > 
   > Here is the newest list:
   > 
   > ---------------------------------------------------------------------------
   > 
   > Views on aggregates fail
   
       Uh oh - Aggregates require a group by clause in the select.
       This is correctly copied into the query action in the views
       pg_rewrite entry. But the rewrite handler doesn't insert it
       into the parsetree. Thus a wrong execution plan in built.
   
       I'll try some things, but expect to get into trouble if the
       select from the view contains it's own grouping clauses.
   
       Let's see.
   
   > REVOKE ALL ON pg_user FROM PUBLIC crashes if run many times, cache issue(Jan)
   
       Done - sent to Marc - not cvs committed yet!
   
   
   Jan
   
   -- 
   
   #======================================================================#
   # It's easier to get forgiveness for being wrong than for being right. #
   # Let's break this rule - forgive me.                                  #
   #======================================== jwieck@debis.com (Jan Wieck) #
   
   
   

3. Re: [HACKERS] Open 6.3 issues

   Marc Fournier <scrappy@hub.org> — 1998-02-23T17:43:41Z

   On Mon, 23 Feb 1998, Jan Wieck wrote:
   
   > > REVOKE ALL ON pg_user FROM PUBLIC crashes if run many times, cache issue(Jan)
   > 
   >     Done - sent to Marc - not cvs committed yet!
   
   	Is now...
   
   
   
   

4. Re: [HACKERS] Open 6.3 issues

   Jan Wieck <jwieck@debis.com> — 1998-02-23T18:16:44Z

   > 
   > On Mon, 23 Feb 1998, Jan Wieck wrote:
   > 
   > > > REVOKE ALL ON pg_user FROM PUBLIC crashes if run many times, cache issue(Jan)
   > > 
   > >     Done - sent to Marc - not cvs committed yet!
   > 
   > 	Is now...
   
   	Arrrg
   
   	Please add the line 
   
   		if (!bootstrap)
   
   	above the 
   		
   		InitLocalInvalidateData();
   
   	in postinit.c manually. Calling it in bootstrap mode causes
   	postgres to dump core. With that test everything is fine.
   
   
   Thanks, Jan
   
   -- 
   
   #======================================================================#
   # It's easier to get forgiveness for being wrong than for being right. #
   # Let's break this rule - forgive me.                                  #
   #======================================== jwieck@debis.com (Jan Wieck) #
   
   
   

5. Re: [HACKERS] Open 6.3 issues

   Vadim Mikheev <vadim@sable.krasnoyarsk.su> — 1998-02-24T01:19:52Z

   Jan Wieck wrote:
   > 
   > > Views on aggregates fail
   > 
   >     Uh oh - Aggregates require a group by clause in the select.
   >     This is correctly copied into the query action in the views
   >     pg_rewrite entry. But the rewrite handler doesn't insert it
   >     into the parsetree. Thus a wrong execution plan in built.
   > 
   >     I'll try some things, but expect to get into trouble if the
   >     select from the view contains it's own grouping clauses.
   
   There is another way of VIEW implementation: put VIEW' query
   as subselect into FROM clause. The last feature is not implemented
   yet. It's just a thought...
   
   Vadim