all forms of foreign keys be exposed to SQLForeignKeys.  This patch is in
addition to the ones I mailed yesterday (forget had I changed that as
well....)

Michael Fork - CCNA - MCP - A+
Network Support - Toledo Internet Access - Toledo Ohio

return foreign key information based on the pg_trigger system table.  I
have tested the patch with (what I believe) is all possible
primary/foreign key combinations -- however I may have missed some, so if
anyone feels like taking the patch for a test drive, here are some useful
links:

Michael Fork

line 1324:
"left-hand" should be "right-hand"

BTW: new document looks very good!
And the new configure/build process seems much better then before!

Thanks!

Laser

is the only diff not accounted for by fmgr rewrite...

Thanks Chih-Chang Hsieh <cch@cc.kmu.edu.tw> for finding the bug.

varlena type.  (I did not force initdb, but you won't see the fix
unless you do one.)  Also, make sure all index support operators and
functions are careful not to leak memory for toasted inputs; I had
missed some hash and rtree support ops on this point before.

mostly just on the WAL logfile nowadays.  But if people want to disable
fsync for performance, why should we say no?

value greater than one.  The behavior this sought to disallow doesn't
seem any less confusing than the other behaviors of cached sequences.
Improve wording of some error messages, too.
Update documentation accordingly.  Also add an explanation that
aborted transactions do not roll back their nextval() calls; this
seems to be a FAQ, so it ought to be mentioned here...

or return type.

or return type.

or return type.

length is less than original string length.

As I read it, the spec requires a non-null result in some cases where
one of the inputs is NULL: specifically, if the other endpoint of that
interval is between the endpoints of the other interval, then the result
is known TRUE despite the missing endpoint.  The spec could've been a
lot simpler if they did not intend this behavior.
I did not force an initdb for this change, but if you don't do one you'll
still see the old strict-function behavior.

if the transaction has already been committed ?