- 12 Mar, 1997 1 commit
-
-
Marc G. Fournier authored
Subject: [HACKERS] equal column and table name patch This fixes a bug where selects fail when there is a column with the same name as the table it's a part of.
-
- 02 Mar, 1997 1 commit
-
-
Bruce Momjian authored
-
- 07 Feb, 1997 1 commit
-
-
Bruce Momjian authored
-
- 22 Jan, 1997 1 commit
-
-
Bruce Momjian authored
Invalidate vacuum relation cache to use new row counts from vacuum.
-
- 17 Dec, 1996 1 commit
-
-
Bruce Momjian authored
-
- 30 Nov, 1996 1 commit
-
-
Bruce Momjian authored
as ints and longs. Touches on quite a few function args as well. Most other files look ok as far as Oids go...still checking though... Since Oids are type'd as unsigned ints, they should prolly be used with the %ud format string in elog and sprintf messages. Not sure what kind of strangeness that could produce. Darren King
-
- 29 Nov, 1996 1 commit
-
-
Bruce Momjian authored
-
- 26 Nov, 1996 1 commit
-
-
Bryan Henderson authored
-
- 13 Nov, 1996 1 commit
-
-
Marc G. Fournier authored
Changes: * Unique index capability works using the syntax 'create unique index'. * Duplicate OID's in the system tables are removed. I put little scripts called 'duplicate_oids' and 'find_oid' in include/catalog that help to find and remove duplicate OID's. I also moved 'unused_oids' from backend/catalog to include/catalog, since it has to be in the same directory as the include files in order to work. * The backend tries converting the name of a function or aggregate to all lowercase if the original name given doesn't work (mostly for compatibility with ODBC). * You can 'SELECT NULL' to your heart's content. * I put my _bt_updateitem fix in instead, which uses _bt_insertonpg so that even if the new key is so big that the page has to be split, everything still works. * All literal references to system catalog OID's have been replaced with references to define'd constants from the catalog header files. * I added a couple of node copy functions. I think this was a preliminary attempt to get rules to work.
-
- 10 Nov, 1996 1 commit
-
-
Bruce Momjian authored
-
- 08 Nov, 1996 1 commit
-
-
Bruce Momjian authored
-
- 06 Nov, 1996 1 commit
-
-
Marc G. Fournier authored
-
- 04 Nov, 1996 2 commits
-
-
Bruce Momjian authored
-
Bruce Momjian authored
-
- 31 Oct, 1996 1 commit
-
-
Bruce Momjian authored
Added needed include file.
-
- 30 Oct, 1996 1 commit
-
-
Bruce Momjian authored
-
- 14 Oct, 1996 1 commit
-
-
Bruce Momjian authored
-
- 13 Oct, 1996 1 commit
-
-
Bruce Momjian authored
cache. I found if I manually added a line to flush the whole relation cache, the assert error disappeared. Looking through the code, I found that the relation cache is flushed at the end of each query if the reference count is zero for the relation. However, printf's showed that the rd_relcnt(reference count) for the accessed query was not returning to zero after each query. It turns out the parser was doing a heap_ropen in parser/analyze.c to get information about the table's columns, but was not doing a heap_close. This was causing the query after the ALTER TABLE ADD to see the old table structure, and the executor's assert was reporting the problem.
-
- 06 Aug, 1996 2 commits
-
-
Marc G. Fournier authored
Previously Postgres95 wouldn't accept 'order by' clauses with fields referred to as '<table>.<field>', e.g.: select t1.field1, t2.field2 from table1 t1, table2 t2 order by t2.field2; This syntax is required by the ODBC SQL spec. Submitted by: Dan McGuirk <mcguirk@indirect.com>
-
Marc G. Fournier authored
While a normal SELECT statement can contain a GROUP BY clause, a cursor declaration cannot. This was not the case in PG-1.0. Was there a good reason why this was changed? Are cursors being phased out? Is there any way to get data with just a SELECT (and without a DECLARE CURSOR ...)? The patch below seems to fix things. If anyone can see a problem with it, please let me know. Thanks. Submitted by: David Smith <dasmith@perseus.tufts.edu>
-
- 20 Jul, 1996 1 commit
-
-
Marc G. Fournier authored
The updating of array fields is broken in Postgres95-1.01, An array can be only replaced with a new array but not have some elements modified. This is caused by two bugs in the parser and in the array utilities. Furthermore it is not possible to update array with a base type of variable length. - submitted by: Massimo Dal Zotto <dz@cs.unitn.it>
-
- 19 Jul, 1996 1 commit
-
-
Marc G. Fournier authored
I have written some patches which add support for NULLs to Postgres95. In fact support for NULLs was already present in postgres, but it had been disabled because not completely debugged, I believe. My patches simply add some checks here and there. To enable the new code you must add -DNULL_PATCH to CFLAGS in Makefile.global. After recompiling you can do things like: insert into a (x, y) values (1, NULL); update a set x = NULL where x = 0; You can't still use a "where x=NULL" clause, you must use ISNULL instead. This could probably be an easy fix to do. Submitted by: Massimo Dal Zotto <dz@cs.unitn.it>
-
- 09 Jul, 1996 1 commit
-
-
Marc G. Fournier authored
-