aboutsummaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAge
* Used LEFT OUTER JOIN for various queriesPhilip Warner2001-01-28
|
* Applied (slightly modified) patches from Tatsuo:Philip Warner2001-01-28
| | | | | | Ok. I have made patches for fixing some of pg_dump problems(see attached patches). The patches address the problem with user defined functions, operators and aggregates.
* Here is an update on the Win32 patch. Modified files are 'config.h.win32'Bruce Momjian2001-01-27
| | | | | | | | | | | | | | | | | and two 'win32.mak'. Addresses the following: 1) Oops. Spelled fcntl.h wrong in the last one. D'uh. 2) PG_VERSION changed to be defined with " around it. psql/command.c failed to compile without that. 3) Changed makefiles to use "/MD" and link both psql and libpq.dll against MSVCRT.DLL instead of a static library. This takes care of the crash-upon-free in psql. I *think* this is what is on the "Open 7.1 Items" list as "Magnus Hagander ODBC Issues?". It has nothing to do with ODBC, but it's the only issue I've been involved with... Magnus Hagander
* Add missing pgaccess files.Bruce Momjian2001-01-27
|
* Update to pgaccess 0.98.7.Bruce Momjian2001-01-27
|
* When dropping the schema, reconnect as owner of each object.Philip Warner2001-01-27
|
* Add permission check for CHECKPOINT.Peter Eisentraut2001-01-27
|
* Fix failure to create sequences for more than one SERIAL column in aTom Lane2001-01-27
| | | | table.
* Looks like I broke cases involving combinations of deferred update/deleteTom Lane2001-01-27
| | | | triggers ... oops ... but the regress tests should have covered this ...
* Don't crash if subquery appears multiple times in jointree. This shouldTom Lane2001-01-27
| | | | | not happen anyway, but let's try not to get completely confused if it does (due to rewriter bugs or whatever).
* Repair bug reported by Huxton, 1/24/01. We need to include a rule'sTom Lane2001-01-27
| | | | | | | | 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.
* Just a quick patch to make the geometry test on Sparc/LinuxBruce Momjian2001-01-27
| | | | | | | | | | 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
* Refuse to try to attach a condition to a NOTIFY or other utility statement,Tom Lane2001-01-27
| | | | | | 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.
* Suppress coredump when EXPLAINing query that is rewritten to includeTom Lane2001-01-27
| | | | a NOTIFY.
* Re-read Unix-socket lock file every so often (every CheckPoint interval,Tom Lane2001-01-27
| | | | | | 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 ...
* Change float8-to-int8 conversion to round to nearest, rather thanTom Lane2001-01-26
| | | | | | | 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.
* odbc1.diff changes the text on the Protocol Radio buttons on the driverBruce Momjian2001-01-26
| | | | | | | | | | | | | | 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
* gcc complains about improperly terminated comment.Tom Lane2001-01-26
|
* Special case in ProcSleep() wasn't sufficiently general: must check toTom Lane2001-01-26
| | | | | see if we shouldn't block whenever we insert ourselves anywhere before the end of the queue, not only at the front.
* First step in attempt to fix tree at runtime: create upper levelsVadim B. Mikheev2001-01-26
| | | | | | | 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.
* Synced gram.y and preproc.y.Michael Meskes2001-01-25
|
* For missing owner of database, default to superuser.Peter Eisentraut2001-01-25
|
* Avoid bogus failures due to 'ps x | grep postmaster' detecting 'grepPeter Eisentraut2001-01-25
| | | | postmaster' process.
* Added an alternative constructor to PGSQLException so that debuggingPeter Mount2001-01-25
| | | | | | | | 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.
* Whoops, forgot to do ProcLockWakeup() after deadlock checkerTom Lane2001-01-25
| | | | rearranges wait queues.
* Re-implement deadlock detection and resolution, per design notes postedTom Lane2001-01-25
| | | | to pghackers on 18-Jan-01.
* Further to the previous ODBC patches I posted today, I found a couple ofBruce Momjian2001-01-25
| | | | | | | | | | | | | | | | | | | | 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
* > From: Tom Lane [mailto:tgl@sss.pgh.pa.us]Bruce Momjian2001-01-25
| | | | | | | | | | | | | | | | | > 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
* I decided to give this a go after all :-) The attached patch does theBruce Momjian2001-01-25
| | | | | | | | | | | | | | | | | | | | 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
* This patch fixes an arrayindexoutofbounds exception that was justBruce Momjian2001-01-25
| | | | | | | introduced into the code. The fix is a fix to org.postgresql.core.ByteArrayDim1.java. Barry Lind
* Add ./include/config.h.win32 to RELEASE update list.Bruce Momjian2001-01-25
|
* Attached is a revised patch that removes the static SimpleDateFormatBruce Momjian2001-01-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Change Copyright from PostgreSQL, Inc to PostgreSQL Global Development Group.Bruce Momjian2001-01-24
|
* Fix bogus pattern for STRING.Peter Eisentraut2001-01-24
|
* Add all possible config file options.Bruce Momjian2001-01-24
|
* Put back old config contents until I am finished.Bruce Momjian2001-01-24
|
* Add "idle in transaction" status messageBruce Momjian2001-01-24
|
* Fix formatting of db crash.Bruce Momjian2001-01-24
|
* Removed the 8k row limit reported by DatabaseMetaDataPeter Mount2001-01-24
|
* Add comment for getpwid() safety.Bruce Momjian2001-01-24
|
* attached is take-2 of a patch which fixes a bug relatedBruce Momjian2001-01-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | to the use of getpwuid when running in standalone mode. this patch allocates some persistent storage (using strdup) to store the username obtained with getpwuid in src/backend/main/main.c. this is necessary because later on, getpwuid is called again (in ValidateBinary). the man pages for getpwuid on SCO OpenServer, FreeBSD, and Darwin all have words to this effect (this is from the SCO OpenServer man page): Note ==== All information is contained in a static area, so it must be copied if it is to be saved. Otherwise, it may be overwritten on subsequent calls to these routines. in particular, on my platform, the storage used to hold the pw_name from the first call is overwritten such that it looks like an empty username. this causes a problem later on in SetSessionUserIdFromUserName. i'd assume this isn't a problem on most platforms because getpwuid is called with the same UID both times, and the same thing ends up happening to that static storage each time. however, that's not guaranteed, and is _not_ what happens on my platform (at least :). this is for the version of 7.1 available via anon cvs as of Tue Jan 23 15:14:00 2001 PST: .../src/backend/main/main.c,v 1.37 2000/12/31 18:04:35 tgl Exp -michael thornburgh, zenomt@armory.com
* Here is a patch to make the current snapshot compile on Win32 (native, libpqBruce Momjian2001-01-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | and psql) again. Changes are: 1) psql requires the includes of "io.h" and "fcntl.h" in command.c in order to make a call to open() work (io.h for _open(), fcntl.h for the O_xxx) 2) PG_VERSION is no longer defined in version.h[.in], but in configure.in. Since we don't do configure on native win32, we need to put it in config.h.win32 :-( 3) Added define of SYSCONFDIR to config.h.win32 - libpq won't compile without it. This functionality is *NOT* tested - it's just defined as "" for now. May work, may not. 4) DEF_PGPORT renamed to DEF_PGPORT_STR I have done the "basic tests" on it - it connects to a database, and I can run queries. Haven't tested any of the fancier functions (yet). However, I stepped on a much bigger problem when fixing psql to work. It no longer works when linked against the .DLL version of libpq (which the Makefile does for it). I have left it linked against this version anyway, pending the comments I get on this mail :-) The problem is that there are strings being allocated from libpq.dll using PQExpBuffers (for example, initPQExpBuffer() on line 92 of input.c). These are being allocated using the malloc function used by libpq.dll. This function *may* be different from the malloc function used by psql.exe - only the resulting pointer must be valid. And with the default linking methods, it *WILL* be different. Later, psql.exe tries to free() this string, at which point it crashes because the free() function can't find the allocated block (it's on the allocated blocks list used by the runtime lib of libpq.dll). Shouldn't the right thing to do be to have psql call termPQExpBuffer() on the data instead? As it is now, gets_fromFile() will just return the pointer received from the PQExpBuffer.data (this may well be present at several places - this is the one I was bitten by so far). Isn't that kind of "accessing the internals of the PQExpBuffer structure" wrong? Instead, perhaps it shuold make a copy of the string, adn then termPQExpBuffer() it? In that case, the string will have been allocated from within the same library as the free() is called. I can get it to work just fine by doing this - changing from (around line 100 of input.c): and the same a bit further down in the same function. But, as I said above, this may be at more places in the code? Perhaps someone more familiar to it could comment on that? What do you think shuld be done about this? Personally, I go by the "If you allocate a piece of memory using an interface, use the same interface to free it", but the question is how to make it work :-) Also, AFAIK this only affects psql.exe, so the changes made to the libpq this patch are required no matter how the other issue is handled. Regards, Magnus
* Removed a dangerours DropRelationBuffers() call.Hiroshi Inoue2001-01-24
|
* Make functional index copy attstorage from the column data type, ratherTom Lane2001-01-24
| | | | | | | than forcing 'plain'. This probably does not matter right now, but I think it needs to be consistent with the regular (not-functional) index case, where attstorage is copied from the underlying table. Clean up some other dead and infelicitous code too.
* Narrow scope of critical section, per discussion 1/19/01.Tom Lane2001-01-23
|
* Do _bt_wrtbuf() outside critical section, per discussion with Vadim 1/19.Tom Lane2001-01-23
|
* The -R option didn't accept an argument, which made it kind of useless.Peter Eisentraut2001-01-23
|
* Give 'a_expr ::= a_expr Op' production a slightly lower precedence thanTom Lane2001-01-23
| | | | | | | | | | Op, so that the sequence 'a_expr Op Op a_expr' will be parsed as a_expr Op (Op a_expr) not (a_expr Op) Op a_expr as formerly. In other words, prefer treating user-defined operators as prefix operators to treating them as postfix operators, when there is an ambiguity. Also clean up a couple of other infelicities in production priority assignment --- for example, BETWEEN wasn't being given the intended priority, but that of AND.
* Subject: Bug in SQLForeignKeys()Bruce Momjian2001-01-23
| | | | | | | | | | | | | | | Query used for checking foreign key triggers returns too many results when there're more than one foreign key in a table. It happens because only table's oid is used to link between pg_trigger with INSERT check and pg_trigger with UPDATE/DELETE check. I think there should be enough to add following conditions into WHERE clause of that query: AND pt.tgconstrname = pg_trigger.tgconstrname AND pt.tgconstrname = pg_trigger_1.tgconstrname /Constantin
* Remove useless leftover global variable Ps_status_buffer.Peter Eisentraut2001-01-23
|
generated by cgit v1.2.3 (git 2.25.1) at 2025-06-01 21:57:37 +0000