Hi,

    who's the parser guru? I need help!

    I have a table t1(a int4, b int4)

    When I

        update t1 set b = 2 where a = 1;

    I get a targetlist with 1 entry and resno=2.

    But when I

        update t1 set b = t2.b where a = t2.a;

    I  get the same 1 entry targetlist with resno=1 for attribute
    "b".  That causes deep deep trouble in  the  rewrite  system,
    when  fixing  the  expressions for *new* variable references.
    *new*.attr defaults to *old*.attr except given in  the  query
    to  be  updated.  When  fixing  *new* references, the rewrite
    system looks up the original parsetree to find a TLE with the
    same  resno as the attribute number in the *new*.attr.  So it
    depends on having the resno same to the attno of  the  result
    relation.

    I'm  absolutely unfamiliar with the parser in this area and I
    don't want to hack around and break things  so  close  before
    6.4.  Who knows how to fix this?

    BTW: up to now the rewrite system looks much better. It works
    for insert, update and delete  when  using  constant  values.
    insert ... select ... works too.


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) #



Fri, 14 Aug 1998 19:05:36 +0200 (MET DST)
jwieck@debis.com (Jan Wieck)
Problem with parser
> Hi,
> 
>     who's the parser guru? I need help!
> 
>     I have a table t1(a int4, b int4)
> 
>     When I
> 
>         update t1 set b = 2 where a = 1;
> 
>     I get a targetlist with 1 entry and resno=2.
> 
>     But when I
> 
>         update t1 set b = t2.b where a = t2.a;
> 
>     I  get the same 1 entry targetlist with resno=1 for attribute
>     "b".  That causes deep deep trouble in  the  rewrite  system,
>     when  fixing  the  expressions for *new* variable references.
>     *new*.attr defaults to *old*.attr except given in  the  query
>     to  be  updated.  When  fixing  *new* references, the rewrite
>     system looks up the original parsetree to find a TLE with the
>     same  resno as the attribute number in the *new*.attr.  So it
>     depends on having the resno same to the attno of  the  result
>     relation.
> 
>     I'm  absolutely unfamiliar with the parser in this area and I
>     don't want to hack around and break things  so  close  before
>     6.4.  Who knows how to fix this?
> 
>     BTW: up to now the rewrite system looks much better. It works
>     for insert, update and delete  when  using  constant  values.
>     insert ... select ... works too.

Let me take a look at this.  I am in the middle of a major patch, so it
may take a day or two.


-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.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)

Fri, 14 Aug 1998 15:06:50 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Problem with parser
> Hi,
> 
>     who's the parser guru? I need help!
> 
>     I have a table t1(a int4, b int4)
> 
>     When I
> 
>         update t1 set b = 2 where a = 1;
> 
>     I get a targetlist with 1 entry and resno=2.
> 
>     But when I
> 
>         update t1 set b = t2.b where a = t2.a;

Is the parser code correct here?  You are actually doing:

         update t1 set b = t2.b from t2 where a = t2.a;
                                ^^^^^^^

I don't have a running system right now because of my other patch.  Can
you send me a tree pointing to the problem?  In the above example, what
is the first resno?  EXPLAIN VERBOSE should give you the plans, and dump
detailed plans into the postmaster log file.

I think I see the problem.  In MakeTargetlistExpr(), we have this code:

    /* Processes target columns that will be receiving results */
    if (pstate->p_is_insert || pstate->p_is_update)
    {
        /*
         * insert or update query -- insert, update work only on one
         * relation, so multiple occurence of same resdomno is bogus
         */
        rd = pstate->p_target_relation;
        Assert(rd != NULL);
--->    resdomno = attnameAttNum(rd, colname);
        attrisset = attnameIsSet(rd, colname);
        attrtype = attnumTypeId(rd, resdomno);
        if ((arrayRef != NIL) && (lfirst(arrayRef) == NIL))
            attrtype = GetArrayElementType(attrtype);
        attrtypmod = rd->rd_att->attrs[resdomno - 1]->atttypmod;
        

This looks bad to me, especially because you have a join going on in the
update.  In fact, the comment clearly shows a false assertion, that ther
is only one relation in UPDATE.

Is the update rewrite code assuming that the resdomno of an updated
column must match the attribute number?  And the join is messing this
up?



> 
>     I  get the same 1 entry targetlist with resno=1 for attribute
>     "b".  That causes deep deep trouble in  the  rewrite  system,
>     when  fixing  the  expressions for *new* variable references.
>     *new*.attr defaults to *old*.attr except given in  the  query
>     to  be  updated.  When  fixing  *new* references, the rewrite
>     system looks up the original parsetree to find a TLE with the
>     same  resno as the attribute number in the *new*.attr.  So it
>     depends on having the resno same to the attno of  the  result
>     relation.
> 
>     I'm  absolutely unfamiliar with the parser in this area and I
>     don't want to hack around and break things  so  close  before
>     6.4.  Who knows how to fix this?
> 
>     BTW: up to now the rewrite system looks much better. It works
>     for insert, update and delete  when  using  constant  values.
>     insert ... select ... works too.
> 
> 
> 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) #
> 
> 
> 
> 


-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.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)

Fri, 14 Aug 1998 15:26:06 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Problem with parser
> This looks bad to me, especially because you have a join going on in the
> update.  In fact, the comment clearly shows a false assertion, that ther
> is only one relation in UPDATE.
>
> Is the update rewrite code assuming that the resdomno of an updated
> column must match the attribute number?  And the join is messing this
> up?
>
> --
> Bruce Momjian                          |  830 Blythe Avenue

    Right!  The  rewrite  code  assumes  that the resdomno of the
    updated columns match the  attribute  number  in  the  target
    relation.   I  don't  know if the join is messing it up - but
    looks like.  Thanks for the help - I think I have to look for
    usage  of  p_last_resno to find all the places where this can
    happen.

    Little joke:

    At the place in analyze.c, where a TLE is created, there is a
    comment  that  not creating a proper target list with correct
    resdomno's might break rules :-)

    I love those comments. And especially  all  that  have  XXXXX
    somewhere.


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) #



Sat, 15 Aug 1998 00:49:03 +0200 (MET DST)
jwieck@debis.com (Jan Wieck)
Re: [HACKERS] Problem with parser
> > This looks bad to me, especially because you have a join going on in the
> > update.  In fact, the comment clearly shows a false assertion, that ther
> > is only one relation in UPDATE.
> >
> > Is the update rewrite code assuming that the resdomno of an updated
> > column must match the attribute number?  And the join is messing this
> > up?
> >
> > --
> > Bruce Momjian                          |  830 Blythe Avenue
> 
>     Right!  The  rewrite  code  assumes  that the resdomno of the
>     updated columns match the  attribute  number  in  the  target
>     relation.   I  don't  know if the join is messing it up - but
>     looks like.  Thanks for the help - I think I have to look for
>     usage  of  p_last_resno to find all the places where this can
>     happen.

OK, do you need me to supply a patch?  I would be glad to review
anything you have.

> 
>     Little joke:
> 
>     At the place in analyze.c, where a TLE is created, there is a
>     comment  that  not creating a proper target list with correct
>     resdomno's might break rules :-)
> 
>     I love those comments. And especially  all  that  have  XXXXX
>     somewhere.

Yes, I have a few favorites.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.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)

Fri, 14 Aug 1998 21:17:41 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Problem with parser
>
> OK, do you need me to supply a patch?  I would be glad to review
> anything you have.

    I   decided   to   reassign   the   redomno's  when  entering
    RewriteQuery() and there's a resultRelation.  It's  the  only
    way  I  think not to miss a single place where a bad resdomno
    is created.


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) #



Sat, 15 Aug 1998 15:56:30 +0200 (MET DST)
jwieck@debis.com (Jan Wieck)
Re: [HACKERS] Problem with parser
> >
> > OK, do you need me to supply a patch?  I would be glad to review
> > anything you have.
> 
>     I   decided   to   reassign   the   redomno's  when  entering
>     RewriteQuery() and there's a resultRelation.  It's  the  only
>     way  I  think not to miss a single place where a bad resdomno
>     is created.

I am going to fix the parser, so you don't have to do this in the
rewrite system.  I will let you know when it is ready.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.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)

Sun, 23 Aug 1998 18:13:04 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Problem with parser
> > This looks bad to me, especially because you have a join going on in the
> > update.  In fact, the comment clearly shows a false assertion, that ther
> > is only one relation in UPDATE.
> >
> > Is the update rewrite code assuming that the resdomno of an updated
> > column must match the attribute number?  And the join is messing this
> > up?
> >
> > --
> > Bruce Momjian                          |  830 Blythe Avenue
> 
>     Right!  The  rewrite  code  assumes  that the resdomno of the
>     updated columns match the  attribute  number  in  the  target
>     relation.   I  don't  know if the join is messing it up - but
>     looks like.  Thanks for the help - I think I have to look for
>     usage  of  p_last_resno to find all the places where this can
>     happen.

Jan, I will be fixing this.

Jan, I am attaching the current TODO list.  Can you tell me which items
are fixed in 6.4?

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.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)

TODO list for PostgreSQL
========================
Last updated:		Mon Aug  3 21:42:02 EDT 1998

Current maintainer:	Bruce Momjian (maillist@candle.pha.pa.us)

The most recent version of this document can be viewed at
the PostgreSQL WWW site, http://www.postgreSQL.org.

THE CHANGES FOR 6.3 APPEAR AT THE END OF THIS DOCUMENT

A dash(-) marks changes to be in the next release.

Developers who have claimed items are:
-------------------------------------
	* Bruce is Bruce Momjian<maillist@candle.pha.pa.us>
	* Bryan is Bryan Henderson<bryanh@giraffe.netgate.net>
	* D'Arcy is D'Arcy J.M. Cain <darcy@druid.net>
	* Dan is Dan McGuirk <mcguirk@indirect.com>
	* Daniel is Daniel Kalchev <daniel@digsys.bg>
	* Darren is Darren King <darrenk@insightdist.com>
	* David is David Hartwig <daveh@insightdist.com>
	* Edmund is Edmund Mergl <E.Mergl@bawue.de>
	* Erich Stamberger <eberger@gewi.kfunigraz.ac.at>
	* Gerhard is Gerhard Reithofer <gerhardr@tech-edv.co.at>
	* Goran is Goran Thyni <goran@bildbasen.se>
	* Henry is Henry B. Hotz <hotz@jpl.nasa.gov>
	* Igor is Igor <igor@sba.miami.edu>
	* Jan is Jan Wieck <wieck@sapserv.debis.de>
	* Jun is Jun Kuwamura <juk@rccm.co.jp>
	* Kurt is "Kurt J. Lidl" <lidl@va.pubnix.com>
	* Maarten is Maarten Boekhold <maartenb@dutepp0.et.tudelft.nl>
 	* Marc is Marc Fournier <scrappy@hub.org>
 	* Martin is Martin S. Utesch <utesch@aut.tu-freiberg.de>
	* Michael is Michael Meskes <meskes@debian.org>
	* Oleg is Oleg Bartunov <oleg@sai.msu.su>
	* Paul is Paul M. Aoki <aoki@CS.Berkeley.EDU>
	* Patrick is Patrick van Kleef <pvk@pobox.com>
	* Peter is Peter T Mount <peter@retep.org.uk>
	* Phil is Phil Thompson <phil@river-bank.demon.co.uk>
	* Raymond is Raymond Toy <toy@rtp.ericsson.se>
	* Soo-Ho Ok <shok@detc.dongeui-tc.ac.kr>
	* Stefan Simkovics <ssimkovi@rainbow.studorg.tuwien.ac.at>
	* Sven is Sven Verdoolaege <skimo@breughel.ufsia.ac.be>
	* Tatsuo is Tatsuo Ishii <t-ishii@sra.co.jp>
	* Thomas is Thomas Lockhart <tgl@mythos.jpl.nasa.gov>
	* Todd is Todd Brandys is <brandys@eng3.hep.uiuc.edu>
	* Vadim is "Vadim B. Mikheev" <vadim@sable.krasnoyarsk.su>
	* Vivek is Vivek Khera <khera@kci.kciLink.com>

Additional 6.3 developers include:
---------------------------------
	* Billy is Billy G. Allie <Bill.Allie@mug.org>
	* Brook is Brook Milligan <brook@trillium.NMSU.Edu>
	* James is James Hughes <jamesh@interpath.com>
	* Jeroen is Jeroen van Vianen <jeroenv@design.nl>
	* Matt is Matt Maycock <maycock@intelliquest.com>
	* Ryan is Ryan Kirkpatrick <rkirkpat@nag.cs.colorado.edu>
	* TomH is Tom I Helbekkmo <tih@Hamartun.Priv.NO>
	* TomS is Tom Szybist
	* Travis is Travis Melhiser <melhiser@viper.co.union.nc.us>

RELIABILITY
-----------
* Overhaul mdmgr/smgr to fix double unlinking and double opens, cleanup
* Overhaul bufmgr/lockmgr/transaction manager
* Remove EXTEND?
* CREATE VIEW requires super-user priviledge
* Can lo_export()/lo_import() read/write anywhere, causing a security problem?
* Tables that start with xinv confused to be large objects
* Two and three dimmensional arrays display improperly, missing {}
* GROUP BY in INSERT INTO table SELECT * FROM table2 fails
* Prevent auto-table reference, like SELECT table.col WHERE col = 3 (?)
* SELECT * FROM table WHERE int4_column = '1' fails
* SELECT a[1] FROM test fails, it needs test.a[1]
* UPDATE table SET table.value = 3 fails
* -Make pg_dump preserve inheritance column order, do non-inherits first
* User who can create databases can modify pg_database table
* optimizer memory exhaustion with many OR's
* elog() does not free all its memory(Jan)
* views on subselects fail
* disallow inherited columns with the same name as new columns
* recover or force failure when disk space is exhausted
* default char() value not to full length crashes server on some OS's
* allow UPDATE using aggregate to affect all rows, not just one
* computations in views fail:
	create view test as select usesysid * usesysid from pg_shadow;
 
ENHANCEMENTS
------------
* Replace table-level locking with row or page-level locking(Vadim)
* Add SERIAL type
* Transaction log, so re-do log can be on a separate disk
* Allow transaction commits with rollback with no-fsync performance
* More access control over who can create tables and access the database
* Add full ANSI SQL capabilities
	* -Implement HAVING clause(Stephan)
	* add OUTER joins, left and right (Thomas)
	* make VIEWs updateable where possible
	* add INTERSECTS, SUBTRACTS(Stephan)
	* add temporary tables
	* add sql3 recursive unions
	* add the concept of dataspaces
	* add DECIMAL, NUMERIC, DOUBLE PRECISION, BIT, BIT VARYING
 	* NCHAR (as distinguished from ordinary varchar),
	* DOMAIN capability
* Allow compression of large fields or a compressed field type
* Fix the rules system(Jan,Soo-Ho)
	* robust
	* making INSTEAD rules work
	* add CONSTRAINT
* Full set of text operations and functions
	* word searches, concat,max() on text, char
* Large objects
	* Fix large object mapping scheme, own reltype(Peter)
	* Allow large text type to use large objects(Peter)
	* not to stuff everything as files in a single directory
	* Fix large object memory leaks
* Better interface for adding to pg_group
* Make MONEY/DECIMAL have a defined precision
* Fix tables >2G, or report error when 2G size reached
	(fix lseek()/off_t, mdextend()/RELSEG_SIZE)
* -Allow libpq to cancel query requests
* Add REGEX internationalization
* allow row re-use without vacuum, maybe?(Vadim)
* -Remove restriction that ORDER BY field must be in SELECT list(David)
* Add word index for text fields, maybe with trigrams, i.e.:
    * ' (cat | dog) & ! fox ' meaning text has cat aor dog, but not fox
* Populate backend status area and write program to dump status data
* Add ALTER TABLE DROP COLUMN feature
* Allow INSERT INTO ... SELECT to convert column types
* Add syslog functionality(Marc)
* Add STDDEV/VARIANCE() function for standard deviation computation/variance
* add UNIQUE capability to non-btree indexes
* make number of backends a config parameter, storage/sinvaladt.h:MaxBackendId
* certain indexes will not shrink, i.e. oid indexes with many inserts
* make NULL's come out at the beginning or end depending on the ORDER BY direction
* change the library/backend interface to use network byte order
* Restore unused oid's on backend exit if no one else has gotten oids
* remove non-standard types from the system, and make them loadable
* have UPDATE/DELETE clean out indexes
* allow WHERE restriction on ctid
* allow pg_descriptions when creating types, tables, columns, and functions
* Fix compile and security of Kerberos/GSSAPI code
* Allow psql to print nulls as distinct from ""(?)
* Allow variable casts with BETWEEN 'today'::asbtime AND 'today'::abstime
* Allow INSERT INTO ... SELECT ... FROM view to work
* Make VACUUM on database not lock pg_class
* Make VACUUM ANALYZE only use a readlock
* Allow cursors to be DECLAREd/OPENed/CLOSEed outside transactions
* Allow installation data block size and max tuple size configuration(Darren)
* Allow views on a UNION
* Allow DISTINCT on view
* Allow views of aggregate columns
* Allow variable block sizes(Darren)
* System tables are now more update-able from SQL(Jan)
* New pg_shadow file, pg_user is now a view of pg_shadow(Jan)
* Allow flag to control COPY input/output of NULLs
* Allow CLUSTER on all tables at once, and improve CLUSTER
* Change all references of Postgres to PostgreSQL, including binary names
* Add ELOG_TIMESTAMPS to elog()(?)
* Change LOCK tablename to LOCK TABLE tablename(?)
* Allow max tuple length to be changed(Darren)
* Have psql with no database name not connect to username as default(?)
* Allow subqueries in target list
* Granting permissions to another user looses permissions for the owner
* Allow queries across multiple databases
* Add replication of distributed databases
* Allow table destruction/alter to be rolled back
* Add pg_attribute.atttypmod/Resdom->restypmod to PGresult structure
* Generate error on CREATE OPERATOR of ~~, ~ and and ~*
* Allow constraint NULL just as we honor NOT NULL
* Allow views to specify column names outside SELECT statement
* Add version number in startup banners for psql and postmaster
* Restructure storing of GRANT permission information to allow +-=
* allow psql \copy to allow delimiters
* allow international error message support and add error codes
* allow ORDER BY a function(David)
* allow usernames with dashes(GRANT fails)
* add a function to return the last inserted oid, for use in psql scripts
* allow creation of functional indexes to use default types

PERFORMANCE
-----------
* Use indexes in ORDER BY for restrictive data sets, min(), max()
* Optimizing disjunctive queries
* Fix bushy-plans
* Other optimizer bugs
* Prevent fsync in SELECT-only queries
* Cache most recent query plan(s?)
* Shared catalog cache, reduce lseek()'s by caching table size in shared area
* Allow compression of log and meta data
* Add FILLFACTOR to index creation
* -Allow indexes to be used with OR clauses(Bruce)
* update pg_statistic table to remove operator column
* make index creation use psort code, because it is now faster(Vadim)
* remove fork()/exec() of backend and make it just fork()
* Add base table name to \d index
* Allow char() not to use variable-sized header to reduce disk size
* Do async I/O to do better read-ahead of data
* Fix optmizer problem with self-table joins
* Fix memory exhaustion when using many OR's
* Use spin locks only on multi-CPU systems, yield CPU instead
* Get faster regex() code from Henry Spencer <henry@zoo.utoronto.ca>
	when it is available
* use mmap() rather than SYSV shared memory(?)
* use index to restrict rows returned by multi-key index when used with
	non-consecutive keys or OR clauses, so fewer heap accesses

DOCUMENTATION
-------------
* Update usermanual source(many)
* added features used in grammer but not in docs, like :: and CAST
* update libpq++ and pginterface manual page
* Add keyword list to documentation, already in /tools
* Add 'man pgsql' to show all manual page names



=============================================================================


CHANGES IN THE 6.3.2 PATCH
--------------------------
configure detection improvements for tcl/tk(Brook Milligan, Alvin)
Manual page improvements(Bruce)
BETWEEN and LIKE fix(Thomas)
fix for psql \connect used by pg_dump(Oliver Elphick)
New odbc driver
pgaccess, version 0.86
qsort removed, now uses libc version, cleanups(Jeroen)
fix for buffer over-runs detected(Maurice Gittens)
fix for buffer overrun in libpgtcl(Randy Kunkee)
fix for UNION with DISTINCT or ORDER BY(Bruce)
gettimeofday configure check(Doug Winterburn)
Fix "indexes not used" bug(Vadim)
docs additions(Thomas)
Fix for backend memory leak(Bruce)
libreadline cleanup(Erwan MAS)
Remove DISTDIR(Bruce)
Makefile dependency cleanup(Jeroen van Vianen)
ASSERT fixes(Bruce)


CHANGES IN THE 6.3.1 PATCH 
--------------------------
ecpg cleanup/fixes, now version 1.1(Michael Meskes)
pg_user cleanup(Bruce)
large object fix for pg_dump and tclsh(alvin@camberlo.demon.co.uk)
LIKE fix for multiple adjacent underscores
LIKE/BETWEEN fix for having function call as target(Thomas)
fix for redefining builtin functions(Thomas)
ultrix4 cleanup
upgrade to pg_access 0.83
updated CLUSTER manual page
multi-byte character set support, see doc/README.mb(Tatsuo)
configure --with-pgport fix
pg_ident fix
big-endian fix for backend communications(Kataoka)
SUBSTR() and substring() fix(Jan)
several jdbc fixes(Peter)
libpgtcl improvements, see libptcl/README(Randy Kunkee)
Fix for "Datasize = 0" error(Vadim)
Prevent \do from wrapping(Bruce)
Remove duplicate Russian character set entries
Sunos4 cleanup
Allow optional TABLE keyword in LOCK and SELECT INTO(Thomas)
CREATE SEQUENCE options to allow a negative integer(Thomas)
Add "PASSWORD" as an allowed column identifier(Thomas)
Add checks for UNION target fields(Bruce)
Fix Alpha port(Dwayne Bailey)
Fix for text arrays containing quotes(Doug Gibson)
Solaris compile fix(Albert Chin-A-Young)
Better identify tcl and tk libs and includes(Bruce)



CHANGES IN THE 6.3 RELEASE
--------------------------

There are some general 6.3 issues that I want to mention.  These are
only the big items that can not be described in one sentence.

First, we now have subselects.  Now that we have them, I would like to
mention that without subselects, SQL is a very limited language.
Subselects are a major feature, and you should review your code for
places where subselects provide a better solution for your queries.  I
think you will find that there are more uses for subselects than you may
think.  Vadim has put us on the big SQL map with subselects, and fully
functional ones too.  The only thing you can't do with subselects is to
use them in the target list.

Second, 6.3 uses unix domain sockets rather than TCP/IP by default.  To
enable connections from other machines, you have to use the new
postmaster -i option, and of course edit pg_hba.conf.  Also, for this
reason, the format of pg_hba.conf has changed.

Third, char() fields will now allow faster access than varchar() or
text. Specifically, the text and varchar() have a penalty for access to
any columns after the first column of this type.  char() used to also
have this access penalty, but it no longer does.  This may suggest that
you redesign some of your tables, especially if you have short character
columns that you have defined as varchar() or text.  This and other
changes make 6.3 even faster than earlier releases.

We now have passwords definable independent of any Unix file.  There are
new SQL USER commands.  See the pg_hba.conf manual page for more
information.  There is a new table, pg_shadow, which is used to store
user information and user passwords, and it by default only SELECT-able
by the postgres super-user.  pg_user is now a view of pg_shadow, and is
SELECT-able by PUBLIC.  You should keep using pg_user in your
application without changes.

User-created tables now no longer have SELECT permission to PUBLIC by
default.  This was done because the ANSI standard requires it.  You can
of course GRANT any permissions you want after the table is created. 
System tables continue to be SELECT-able by PUBLIC.

We also have real deadlock detection code.  No more sixty-second
timeouts.  And the new locking code implements a FIFO better, so there
should be less resource starvation during heavy use.

Many complaints have been made about inadequate documenation in previous
releases.  Thomas has put much effort into many new manuals for this
release.  Check out the /doc directory.

For performance reasons, time travel is gone, but can be implemented
using triggers (see pgsql/contrib/spi/README).  Please check out the new
\d command for types, operators, etc.  Also, views have their own
permissions now, not based on the underlying tables, so permissions on
them have to be set separately.  Check /pgsql/interfaces for some new
ways to talk to PostgreSQL.

This is the first release that really required an explaination for
existing users.  In many ways, this was necessary because the new
release removes many limitations, and the work-arounds people were using
are no longer needed.

Bug Fixes
---------
Fix binary cursors broken by MOVE implementation(Vadim)
Fix for tcl library crash(Jan)
Fix for array handling, from Gerhard Hintermayer
Fix acl error, and remove duplicate pqtrace(Bruce)
Fix psql \e for empty file(Bruce)
Fix for textcat on varchar() fields(Bruce)
Fix for DBT Sendproc (Zeugswetter Andres)
Fix vacuum analyze syntax problem(Bruce)
Fix for international identifiers(Tatsuo)
Fix aggregates on inherited tables(Bruce)
Fix substr() for out-of-bounds data
Fix for select 1=1 or 2=2, select 1=1 and 2=2, and select sum(2+2)(Bruce)
Fix notty output to show status result.  -q option still turns it off(Bruce)
Fix for count(*), aggs with views and multiple tables and sum(3)(Bruce)
Fix cluster(Bruce)
Fix for PQtrace start/stop several times(Bruce)
Fix a variety of locking problems like newer lock waiters getting
	lock before older waiters, and having readlock people not share
	locks if a writer is waiting for a lock, and waiting writers not
	getting priority over waiting readers(Bruce)
Fix crashes in psql when executing queries from external files(James)
Fix problem with multiple order by columns, with the first one having
	NULL values(Jeroen)
Use correct hash table support functions for float8 and int4(Thomas)
Re-enable JOIN= option in CREATE OPERATOR statement (Thomas)
Change precedence for boolean operators to match expected behavior(Thomas)
Generate elog(ERROR) on over-large integer(Bruce)
Allow multiple-argument functions in constraint clauses(Thomas)
Check boolean input literals for 'true','false','yes','no','1','0'
	and throw elog(ERROR) if unrecognized(Thomas)
Major large objects fix
Fix for GROUP BY showing duplicates(Vadim)
Fix for index scans in MergeJion(Vadim)

Enhancements
------------
Subselects with EXISTS, IN, ALL, ANY keywords (Vadim, Bruce, Thomas)
New User Manual(Thomas, others)
Speedup by inlining some frequently-called functions
Real deadlock detection, no more timeouts(Bruce)
Add SQL92 "constants" CURRENT_DATE, CURRENT_TIME, CURRENT_TIMESTAMP, 
	CURRENT_USER(Thomas)
Modify constraint syntax to be SQL92-compliant(Thomas)
Implement SQL92 PRIMARY KEY and UNIQUE clauses using indices(Thomas)
Recognize SQL92 syntax for FOREIGN KEY. Throw elog notice(Thomas)
Allow NOT NULL UNIQUE constraint clause (each allowed separately before)(Thomas)
Allow Postgres-style casting ("::") of non-constants(Thomas)
Add support for SQL3 TRUE and FALSE boolean constants(Thomas)
Support SQL92 syntax for IS TRUE/IS FALSE/IS NOT TRUE/IS NOT FALSE(Thomas)
Allow shorter strings for boolean literals (e.g. "t", "tr", "tru")(Thomas)
Allow SQL92 delimited identifiers(Thomas)
Implement SQL92 binary and hexadecimal string decoding (b'10' and x'1F')(Thomas)
Support SQL92 syntax for type coercion of literal strings
	(e.g. "DATETIME 'now'")(Thomas)
Add conversions for int2, int4, and OID types to and from text(Thomas)
Use shared lock when building indices(Vadim)
Free memory allocated for an user query inside transaction block after
	this query is done, was turned off in <= 6.2.1(Vadim)
New SQL statement CREATE PROCEDURAL LANGUAGE(Jan)
New PostgreSQL Procedural Language (PL) backend interface(Jan)
Rename pg_dump -H option to -h(Bruce)
Add Java support for passwords, European dates(Peter)
Use indices for LIKE and ~, !~ operations(Bruce)
Add hash functions for datetime and timespan(Thomas)
Time Travel removed(Vadim, Bruce)
Add paging for \d and \z, and fix \i(Bruce)
Add Unix domain socket support to backend and to frontend library(Goran)
Implement CREATE DATABASE/WITH LOCATION and initlocation utility(Thomas)
Allow more SQL92 and/or Postgres reserved words as column identifiers(Thomas)
Augment support for SQL92 SET TIME ZONE...(Thomas)
SET/SHOW/RESET TIME ZONE uses TZ backend environment variable(Thomas)
Implement SET keyword = DEFAULT and SET TIME ZONE DEFAULT(Thomas)
Enable SET TIME ZONE using TZ environment variable(Thomas)
Add PGDATESTYLE environment variable to frontend and backend initialization(Thomas)
Add PGTZ, PGCOSTHEAP, PGCOSTINDEX, PGRPLANS, PGGEQO
	frontend library initialization environment variables(Thomas)
Regression tests time zone automatically set with "setenv PGTZ PST8PDT"(Thomas)
Add pg_description table for info on tables, columns, operators, types, and
	aggregates(Bruce)
Increase 16 char limit on system table/index names to 32 characters(Bruce)
Rename system indices(Bruce)
Add 'GERMAN' option to SET DATESTYLE(Thomas)
Define an "ISO-style" timespan output format with "hh:mm:ss" fields(Thomas)
Allow fractional values for delta times (e.g. '2.5 days')(Thomas)
Validate numeric input more carefully for delta times(Thomas)
Implement day of year as possible input to date_part()(Thomas)
Define timespan_finite() and text_timespan() functions(Thomas)
Remove archive stuff(Bruce)
Allow for a pg_password authentication database that is separate from
	the system password file(Todd)
Dump ACLs, GRANT, REVOKE permissions(Matt)
Define text, varchar, and bpchar string length functions(Thomas)
Fix Query handling for inheritance, and cost computations(Bruce)
Implement CREATE TABLE/AS SELECT (alternative to SELECT/INTO)(Thomas)
Allow NOT, IS NULL, IS NOT NULL in constraints(Thomas)
Implement UNIONs for SELECT(Bruce)
Add UNION, GROUP, DISTINCT to INSERT(Bruce)
varchar() stores only necessary bytes on disk(Bruce)
Fix for BLOBs(Peter)
Mega-Patch for JDBC...see README_6.3 for list of changes(Peter)
Remove unused "option" from PQconnectdb()
New LOCK command and lock manual page describing deadlocks(Bruce)
Add new psql \da, \dd, \df, \do, \dS, and \dT commands(Bruce)
Enhance psql \z to show sequences(Bruce)
Show NOT NULL and DEFAULT in psql \d table(Bruce)
New psql .psqlrc file startup(Andrew)
Modify sample startup script in contrib/linux to show syslog(Thomas)
New types for IP and MAC addresses in contrib/ip_and_mac(TomH)
Unix system time conversions with date/time types in contrib/unixdate(Thomas)
Update of contrib stuff(Massimo)
Add Unix socket support to DBD::Pg(Goran)
New python interface (PyGreSQL 2.0)(D'Arcy)
New frontend/backend protocol has a version number, network byte order(Phil)
Security features in pg_hba.conf enhanced and documented, many cleanups(Phil)
CHAR() now faster access than VARCHAR() or TEXT
ecpg embedded SQL preprocessor
Reduce system column overhead(Vadmin)
Remove pg_time table(Vadim)
Add pg_type attribute to identify types that need length (bpchar, varchar)
Add report of offending line when COPY command fails
Allow VIEW permissions to be set separately from the underlying tables. 
	For security, use GRANT/REVOKE on views as appropriate(Jan)
Tables now have no default GRANT SELECT TO PUBLIC.  You must
	explicitly grant such permissions.
Clean up tutorial examples(Darren)

Source Tree Changes
-------------------
Add new html development tools, and flow chart in /tools/backend
Fix for SCO compiles
Stratus computer port "Gillies, Robert" <GilliesR@Nichols.com>
Added support for shlib for BSD44_derived & i386_solaris
Make configure more automated(Brook)
Add script to check regression test results
Break parser functions into smaller files, group together(Bruce)
Rename heap_create to heap_create_and_catalog, rename heap_creatr
	to heap_create()(Bruce)
Sparc/Linux patch for locking(TomS)
Remove PORTNAME and reorganize port-specific stuff(Marc)
Add optimizer README file(Bruce)
Remove some recursion in optimizer and clean up some code there(Bruce)
Fix for NetBSD locking(Henry)
Fix for libptcl make(Tatsuo)
AIX patch(Darren)
Change IS TRUE, IS FALSE, ... to expressions using "=" rather than
	function calls to istrue() or isfalse() to allow optimization(Thomas)
Various fixes NetBSD/Sparc related(TomH)
Alpha linux locking(Travis,Ryan)
Change elog(WARN) to elog(ERROR)(Bruce)
FAQ for FreeBSD(Marc)
Bring in the PostODBC source tree as part of our standard distribution(Marc)
A minor patch for HP/UX 10 vs 9(Stan)
New pg_attribute.atttypmod for type-specific info like varchar length(Bruce)
Unixware patches(Billy)
New i386 'lock' for spin lock asm(Billy)
Support for multiplexed backends is removed
Start an OpenBSD port
Start an AUX port
Start a Cygnus port
Add string functions to regression suite(Thomas)
Expand a few function names formerly truncated to 16 characters(Thomas)
Remove un-needed malloc() calls and replace with palloc()(Bruce)
Sun, 23 Aug 1998 21:52:03 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Problem with parser
> Jan, I am attaching the current TODO list.  Can you tell me which items
> are fixed in 6.4?
> 
> -- 
> Bruce Momjian                          |  830 Blythe Avenue
> 


> * CREATE VIEW requires super-user priviledge

    Fixed - regular users can create views and rules

> * views on subselects fail

    Must check that - hope it is already fixed

> * computations in views fail:
> 	create view test as select usesysid * usesysid from pg_shadow;

    Will check this too

> * Add full ANSI SQL capabilities
> 	* -Implement HAVING clause(Stephan)
> 	* add OUTER joins, left and right (Thomas)
> 	* make VIEWs updateable where possible

    Rules can be used to make views updateable

> * Fix the rules system(Jan,Soo-Ho)
> 	* robust
> 	* making INSTEAD rules work
> 	* add CONSTRAINT

    The restricted part of rules are robust and instead rules
    work. Constraints could be implemented as rules but would
    require a new RAISE statement. I'll work on constraints
    for 6.5.

> * Allow INSERT INTO ... SELECT ... FROM view to work

    Should work - will check it.

> * Allow views on a UNION
> * Allow DISTINCT on view
> * Allow views of aggregate columns

    Check - not yet - check

> * Allow views to specify column names outside SELECT statement

    ??? what is meant by that?


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) #


Wed, 26 Aug 1998 11:23:09 +0200 (MET DST)
jwieck@debis.com (Jan Wieck)
TODO (was: Re: [HACKERS] Problem with parser)
> > Jan, I am attaching the current TODO list.  Can you tell me which items
> > are fixed in 6.4?
> > 
> > -- 
> > Bruce Momjian                          |  830 Blythe Avenue
> > 
> 
> 
> > * CREATE VIEW requires super-user priviledge
> 
>     Fixed - regular users can create views and rules
> 
> > * views on subselects fail
> 
>     Must check that - hope it is already fixed
> 
> > * computations in views fail:
> > 	create view test as select usesysid * usesysid from pg_shadow;
> 
>     Will check this too
> 
> > * Add full ANSI SQL capabilities
> > 	* -Implement HAVING clause(Stephan)
> > 	* add OUTER joins, left and right (Thomas)
> > 	* make VIEWs updateable where possible
> 
>     Rules can be used to make views updateable
> 
> > * Fix the rules system(Jan,Soo-Ho)
> > 	* robust
> > 	* making INSTEAD rules work
> > 	* add CONSTRAINT
> 
>     The restricted part of rules are robust and instead rules
>     work. Constraints could be implemented as rules but would
>     require a new RAISE statement. I'll work on constraints
>     for 6.5.
> 
> > * Allow INSERT INTO ... SELECT ... FROM view to work
> 
>     Should work - will check it.
> 
> > * Allow views on a UNION
> > * Allow DISTINCT on view
> > * Allow views of aggregate columns
> 
>     Check - not yet - check
> 
> > * Allow views to specify column names outside SELECT statement
> 
>     ??? what is meant by that?

I have no idea.  I am removing it.  Does anyone else know what it means?

I have updated the TODO list.  If you find more items you have fixed,
let me know.  The rewrite system had a large chunk of the TODO list. 
That is why I was so excited when you said you could fix it.


-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.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)

Wed, 26 Aug 1998 12:23:43 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: TODO (was: Re: [HACKERS] Problem with parser)
On Wed, 26 Aug 1998, Bruce Momjian wrote:

> > > * Allow views to specify column names outside SELECT statement
> > 
> >     ??? what is meant by that?
> 
> I have no idea.  I am removing it.  Does anyone else know what it means?

	Might it have had something to do with the inability to do a WHERE
clause on a field not in the target list?



Wed, 26 Aug 1998 12:52:28 -0400 (EDT)
The Hermit Hacker <scrappy@hub.org>
Re: TODO (was: Re: [HACKERS] Problem with parser)