(thanks!)

if it returns EINTR.

FileWrite, FileSeek.

to generate unnecessarily stupid code.  Tweak macro to describe a series
of store-constant ops, not store/load/store/load/store/load/store.

with encoding other than SQL_ASCII.  Per recent discussion in pghackers.

Fri Feb 17 15:11:00 GMT 2001 peter@retep.org.uk
        - Reduced the object overhead in PreparedStatement by reusing the same
          StringBuffer object throughout. Similarly SimpleDateStamp's are alse
          reused in a thread save manner.
        - Implemented in PreparedStatement: setNull(), setDate/Time/Timestamp
          using Calendar, setBlob(), setCharacterStream()
        - Clob's are now implemented in ResultSet & PreparedStatement!
        - Implemented a lot of DatabaseMetaData & ResultSetMetaData methods.
          We have about 18 unimplemented methods left in JDBC2 at the current
          time.

if the return datatype's input converter was at all strict, because the
converter would get called on junk data when returning NULL.  Also
ensure that it gives an error rather than coredumping if someone tries
to use it in a trigger function.

1. If there is exactly one pg_operator entry of the right name and oprkind,
oper() and related routines would return that entry whether its input type
had anything to do with the request or not.  This is just premature
optimization: we shouldn't return the single candidate until after we verify
that it really is a valid candidate, ie, is at least coercion-compatible
with the given types.

2. oper() and related routines only promise a coercion-compatible result.
Unfortunately, there were quite a few callers that assumed the returned
operator is binary-compatible with the given datatype; they would proceed
to call it without making any datatype coercions.  These callers include
sorting, grouping, aggregation, and VACUUM ANALYZE.  In general I think
it is appropriate for these callers to require an exact or binary-compatible
match, so I've added a new routine compatible_oper() that only succeeds if
it can find an operator that doesn't require any run-time conversions.
Callers now call oper() or compatible_oper() depending on whether they are
prepared to deal with type conversion or not.

The upshot of these bugs is revealed by the following silliness in PL/Tcl's
selftest: it creates an operator @< on int4, and then tries to use it to
sort a char(N) column.  The system would let it do that :-( (and evidently
has done so since 6.3 :-( :-().  The result in this case was just a silly
sort order, but the reverse combination would've provoked coredump from
trying to dereference integers.  With this fix you get more reasonable
behavior:
pltcl_test=# select * from T_pkey1 order by key1, key2 using @<;
ERROR:  Unable to identify an operator '@<' for types 'bpchar' and 'bpchar'
        You will have to retype this query using an explicit cast

automatically to compensate the lack of automatic
conversion functionality of PostgreSQL server.
For example if there's a numeric type binding
   1.2567 --> 1.2567::numeric.
I hope this change would enable the use of numeric
type in MS-Access etc.

Thanks Hiroki Kataoka for his checking my code.

relations.  It's not very bright, but at least it now knows that
A LEFT JOIN B must produce at least as many rows as are in A ...

compressed storage works perfectly well.  Might as well have a coherent
strategy for applying it, rather than the haphazard store-what-you-get
approach that was in the code before.  The strategy I've set up here is
to attempt compression of any compressible index value exceeding
BLCKSZ/16, or about 500 bytes by default.

the old ones were not small enough to ensure r-tree and gist indexes would
get picked when available.  These numbers are totally bogus anyway, but
in the absence of any real estimation technique, we'd like to select
indexes when available ...

   per recent discussion in pgsql-odbc. Now SELECT is
   a boundary but VACUUM isn't.
2) Put back the error handling behavior. When elog(ERROR)
   was detected the driver automatically issue "ABORT"
   if a transaction is in progress.
3) Driver version is 7.01.0003(Dave already set it but
   it was put back).

to ON and USING for specifying the join condition, not as an independent
kind of join semantics.

Eiji Tokuya" <e-tokuya@Mail.Sankyo-Unyu.co.jp>

such as
    SELECT f1 FROM foo UNION SELECT ... ORDER BY upper(f1)
to draw
'ORDER BY on a UNION/INTERSECT/EXCEPT result must be on one of the result columns'
rather than the uninformative 'f1 not found' we were producing before.
Eventually this should actually work, but that looks much too hard to try
to implement in late beta...

specifies redundant UNIQUE conditions.