- 27 1月, 2001 18 次提交
-
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
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
-
由 Tom Lane 提交于
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.
-
由 Tom Lane 提交于
a NOTIFY.
-
由 Tom Lane 提交于
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 ...
-
由 Peter Eisentraut 提交于
<jburton@scw.org>.
-
由 Tom Lane 提交于
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.
-
由 Bruce Momjian 提交于
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
-
由 Tom Lane 提交于
-
由 Bruce Momjian 提交于
-
由 Peter Eisentraut 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Tom Lane 提交于
see if we shouldn't block whenever we insert ourselves anywhere before the end of the queue, not only at the front.
-
- 26 1月, 2001 4 次提交
-
-
由 Vadim B. Mikheev 提交于
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.
-
由 Michael Meskes 提交于
-
由 Peter Eisentraut 提交于
-
由 Peter Eisentraut 提交于
postmaster' process.
-
- 25 1月, 2001 18 次提交
-
-
由 Peter Mount 提交于
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.
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Tom Lane 提交于
rearranges wait queues.
-
由 Bruce Momjian 提交于
-
由 Tom Lane 提交于
to pghackers on 18-Jan-01.
-
由 Bruce Momjian 提交于
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
-
由 Bruce Momjian 提交于
> 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
-
由 Bruce Momjian 提交于
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
-
由 Bruce Momjian 提交于
introduced into the code. The fix is a fix to org.postgresql.core.ByteArrayDim1.java. Barry Lind
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
objects that Thomas pointed out might be a problem. PPS. I have included and updated the comments from the original patch request to reflect the changes made in this revised patch. > Attached is a set of patches for a couple of bugs dealing with > timestamps in JDBC. > > Bug#1) Incorrect timestamp stored in DB if client timezone different > than DB. > The buggy implementation of setTimestamp() in PreparedStatement simply > used the toString() method of the java.sql.Timestamp object to convert > to a string to send to the database. The format of this is yyyy-MM-dd > hh:mm:ss.SSS which doesn't include any timezone information. Therefore > the DB assumes its timezone since none is specified. That is OK if the > timezone of the client and server are the same, however if they are > different the wrong timestamp is received by the server. For example if > the client is running in timezone GMT and wants to send the timestamp > for noon to a server running in PST (GMT-8 hours), then the server will > receive 2000-01-12 12:00:00.0 and interprete it as 2000-01-12 > 12:00:00-08 which is 2000-01-12 04:00:00 in GMT. The fix is to send a > format to the server that includes the timezone offset. For simplicity > sake the fix uses a SimpleDateFormat object with its timezone set to GMT > so that '+00' can be used as the timezone for postgresql. This is done > as SimpleDateFormat doesn't support formating timezones in the way > postgresql expects. > > Bug#2) Incorrect handling of partial seconds in getting timestamps from > the DB > > When the SimpleDateFormat object parses a string with a format like > yyyy-MM-dd hh:mm:ss.SS it expects the fractional seconds to be three > decimal places (time precision in java is miliseconds = three decimal > places). This seems like a bug in java to me, but it is unlikely to be > fixed anytime soon, so the postgresql code needed modification to > support the java behaviour. So for example a string of '2000-01-12 > 12:00:00.12-08' coming from the database was being converted to a > timestamp object with a value of 2000-01-12 12:00:00.012GMT-08:00. The > fix was to check for a '.' in the string and if one is found append on > an extra zero to the fractional seconds part. > > > I also did some cleanup in ResultSet.getTimestamp(). This method has > had multiple patches applied some of which resulted in code that was no > longer needed. For example the ISO timestamp format that postgresql > uses specifies the timezone as an offset like '-08'. Code was added at > one point to convert the postgresql format to the java one which is > GMT-08:00, however the old code was left around which did nothing. So > there was code that looked for yyyy-MM-dd hh:mm:sszzzzzzzzz and > yyyy-MM-dd hh:mm:sszzz. This second format would never be encountered > because zzz (i.e. -08) would be converted into the former (also note > that the SimpleDateFormat object treats zzzzzzzzz and zzz the same, the > number of z's does not matter). > > > There was another problem/fix mentioned on the email lists today by > mcannon@internet.com which is also fixed by this patch: > > Bug#3) Fractional seconds lost when getting timestamp from the DB > A patch by Jan Thomea handled the case of yyyy-MM-dd hh:mm:sszzzzzzzzz > but not the fractional seconds version yyyy-MM-dd hh:mm:ss.SSzzzzzzzzz. > The code is fixed to handle this case as well. Barry Lind
-
由 Peter Eisentraut 提交于
-
由 Peter Eisentraut 提交于
-
由 Bruce Momjian 提交于
-