to the client before closing the connection.  Before 7.2 this was done
correctly, but new code would simply close the connection with no report
to the client.

> Looking at this I also found an ecpg TODO list in the docs:
>
>
http://candle.pha.pa.us/main/writings/pgsql/sgml/ecpg-develop.html
>
> Seems that TODO section should be removed.  Some items are done,
others
> are on the main TODO list.

That's correct. I did not fix the docs for quite some time.

Michael
--
Michael Meskes

database.)

from Hiroshi.

a get on a bytea value the code was running the raw value from the server
through character set conversion, which if the character set was SQL_ASCII
would cause all 8bit characters to become ?'s.

< * Consider use of open/fctl(O_DIRECT) to minimize OS caching
---
> * Consider use of open/fcntl(O_DIRECT) to minimize OS caching

> * Consider use of open/fctl(O_DIRECT) to minimize OS caching
> * Make blind writes go through the file descriptor cache
391d392
< * Make blind writes go through the file descriptor cache
409d409
< * Consider use of open/fctl(O_DIRECT) to minimize OS caching

> * Consider use of open/fctl(O_DIRECT) to minimize OS caching

---------------------------------------------------------------------------

When you run 'ecpg --help' you get the following:

          -t   turn on autocommit of transactions

amongst the other options... Shouldn't this be OFF as per the
documentation?

Best regards, Lee.

--
 Lee Kindness,   Senior Software Engineer,   lkindness@csl.co.uk

<   perhaps CREATE DATABASE dbname WITH USER = "user" (Gavin)
---
>   perhaps CREATE DATABASE dbname WITH OWNER = "user" (Gavin)

> * Allow command blocks that can ignore certain types of errors

Move some tabular information on these from the chapter on data types to
 the appendix on dates and times.

Fixes time zone problems introduced by Thomas' implementation of
 TIMESTAMP WITHOUT TIME ZONE which caused the behavior of the previously
 appropriate routine, timestamp_date(), to change for the worse in this
 context.

<   perhaps CREATE DATABASE dbname WITH USER = "user"
---
>   perhaps CREATE DATABASE dbname WITH USER = "user" (Gavin)

< * Allow only owner to create indexes

Disallow CREATE INDEX on system catalogs, non-tables (views, sequences, etc).
Disallow CREATE/DROP TRIGGER on system catalogs, non-tables.
Disallow ALTER TABLE ADD/DROP CONSTRAINT on system catalogs.
Disallow FOREIGN KEY reference to non-table.
None of these things can actually work in the present system structure,
but the code was letting them pass without complaint.

start up, wait until a psql connection attempt succeeds.  Per gripe
from Jason Tishler.

< 	  allow error codes to be specified; requires nested transactions
---
> 	  allow error codes to be specified; requires savepoints
321c321
< * Allow nested transactions / savepoints [transactions]
---
> * Allow savepoints / nested transactions [transactions]

< 	  allow error codes to be specified
---
> 	  allow error codes to be specified; requires nested transactions

portal's memory context, so that they will live as long as the portal does.

> 	o Allow COPY to report error lines and continue;  optionally
> 	  allow error codes to be specified

> * Make equals sign optional in CREATE DATABASE WITH param = 'val'

> * Prevent create/drop scripts from allowing extra args (Bruce)

> * Allow only owner to create indexes

< * Add config file check for $ODBCINI, $HOME/.odbc.ini, and /etc/odbc.ini
---
> * Add config file check for $ODBCINI, $HOME/.odbc.ini, installpath/etc/odbc.ini

Took test from createlang.

> * Add config file check for $ODBCINI, $HOME/.odbc.ini, and /etc/odbc.ini

> * Make it easier to create a database owned by someone who can't createdb,
>   perhaps CREATE DATABASE dbname WITH USER = "user"

wrote:
> > > Just testing pgcrypto on freebsd/alpha.  I get some warnings:
> > They should be harmless, although I should fix them.
>
> The actual code is:
>
>     if ((dlen & 15) || (((unsigned) res) & 3))
>         return -1;

> Hard to imagine how (uint *) & 3 makes any sense, unless res isn't
> always a (uint8 *).  Is that true?

At some point it was casted to (uint32*) so I wanted to be sure its ok.
ATM its pointless.  Please apply the following patch.

--
marko