triggers ... oops ... but the regress tests should have covered this ...

(sql490.htm), there is

"set of all k-tuples v1, v2, ... vk, such that v1 [isin] D1, v1 [isin] D1"

i assume it should be
"set of all k-tuples v1, v2, ... vk, such that v1 [isin] D1, v2 [isin] D2"

Divide by Zero

not happen anyway, but let's try not to get completely confused if it does
(due to rewriter bugs or whatever).

original table ('OLD' table) in its join tree if OLD is referenced by
either the rule action, the rule qual, or the original query qual that
will be added to the rule action.  However, we only want one instance
of the original table to be included; so beware of the possibility that
the rule action already has a jointree entry for OLD.

regression tests for Pgsql 7.1beta3 pass. This is very similr to the one I
submitted back in July for Linux/Alpha. Apparently non-x86 Linux machines
like to compute nth place float point digits like Sun/Solaris does?
        Otherwise, 7.1beta3 runs without problems (i.e. all other
regression tests pass) on my Sparc 20 running Debian GNU/Linux 2.2.

Ryan Kirkpatrick

rather than coredumping (as prior 7.1 code did) or silently dropping the
condition (as 7.0 did).  This is annoying but there doesn't seem to be
any good way to fix it, short of a major querytree restructuring.

a NOTIFY.

actually) to ensure that its file access time doesn't get old enough to
tempt a /tmp directory cleaner to remove it.  Still another reason we
should never have put the sockets in /tmp in the first place ...

<jburton@scw.org>.

truncating to integer.  Remove regress test that checks whether
4567890123456789 can be converted to float without loss; since that's
52 bits, it's on the hairy edge of failing with IEEE float8s, and indeed
rint seems to give platform-dependent results for it.

dialogue from '6.4/6.5' to '6.5+' and removes some C++ comments from
resource.h (which VC++ insists on putting there).

odbc2.diff adds code to query the PostgreSQL version upon connection. This
is then used to determine what values to return for from SQLGetInfo for
SQL_DBMS_VER, SQL_MAX_ROW_SIZE, SQL_MAX_STATEMENT_LEN, SQL_OJ_CAPABILITIES
and SQL_OUTER_JOINS. The version string as returned by SELECT vERSION() (as
a char array) and the major.minor version number (as a flost) have been
added to the ConnectionClass structure.

Dave Page

see if we shouldn't block whenever we insert ourselves anywhere before
the end of the queue, not only at the front.

and new root page if old root one was splitted but new root page
wasn't created.
New code is protected by FixBTree bool flag setted to FALSE, so
nothing should be affected by this untested approach.

postmaster' process.

          some more osteric bugs is easier. If only 1 arg is supplied and it's
          of type Exception, then that Exception's stacktrace is now included.

This was done as there's been a report of an unusual bug during connection.
This will make this sort of bug hunting easier from now on.

rearranges wait queues.

to pghackers on 18-Jan-01.

problems with char array sizes having set a couple of constants to 0 for
unlimited query length and row length. This additional patch cleans those
problems up by defining a new constant (STD_STATEMENT_LEN) to 65536 and
using that in place of MAX_STATEMENT_LEN.

Another constant (MAX_MESSAGE_LEN) was defined as 2*BLCKSZ, but is now
65536. This is used to define the length of the message buffer in a number
of places and as I understand it (probably not that well!) therefore also
places a limit on the query length. Fixing this properly is beyond my
capabilities but 65536 should hopefully be large enough for most people.

Apologies for being over-enthusiastic and posting 3 patches in one day
rather than 1 better tested one!

Regards,

Dave Page

> Sent: 24 January 2001 16:51
> To: Dave Page
> Subject: Re: [PATCHES] ODBC Patch for OJs/Large Querys & Rows
>
>
> > SQL_OJ_LEFT = Left outer joins are supported.
>
> Yes.
<snip>

In addition to my earlier patch, this one adds support for SQLGetInfo
SQL_OJ_CAPABILITIES to the ODBC driver.

Dave Page

following but it does *not* check whether the user is connected to
PostgreSQL 7.0.x or 7.1 first (as would be required for some of the
features) - the driver doesn't do this at all afaik and it's beyond my
capabilities to implement such checking in code that doesn't look like it
was written by my 1 year old daughter!

1) The driver now reports no maximum query length (SQL_MAX_QUERY_SIZE).
2) The driver now reports no maximum row length (SQL_MAX_ROW_SIZE).
3) The driver now reports that Outer Joins are supported (SQL_OUTER_JOINS),
but still does not report oj capabilities (SQL_OJ_CAPABILITIES).
4) The version number has been incremented to 7.1.0000 in psqlodbc.h *and*
psqlodbc.rc


Regards,

Dave Page

introduced into the code.  The fix is a fix to
org.postgresql.core.ByteArrayDim1.java.

Barry Lind