1. 12 Mar, 1997 1 commit
  2. 02 Mar, 1997 1 commit
  3. 07 Feb, 1997 1 commit
  4. 22 Jan, 1997 1 commit
  5. 17 Dec, 1996 1 commit
  6. 30 Nov, 1996 1 commit
    • Bruce Momjian's avatar
      This patch changes quite a few instances of references of Oid's · 63df35e2
      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
      63df35e2
  7. 29 Nov, 1996 1 commit
  8. 26 Nov, 1996 1 commit
  9. 13 Nov, 1996 1 commit
    • Marc G. Fournier's avatar
      Commit of a *MAJOR* patch from Dan McGuirk <djm@indirect.com> · 07a65b22
      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.
      07a65b22
  10. 10 Nov, 1996 1 commit
  11. 08 Nov, 1996 1 commit
  12. 06 Nov, 1996 1 commit
  13. 04 Nov, 1996 2 commits
  14. 31 Oct, 1996 1 commit
  15. 30 Oct, 1996 1 commit
  16. 14 Oct, 1996 1 commit
  17. 13 Oct, 1996 1 commit
    • Bruce Momjian's avatar
      I checked the alter table code, and started suspecting the relation · abb1b3e7
      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.
      abb1b3e7
  18. 06 Aug, 1996 2 commits
    • Marc G. Fournier's avatar
      Fixes: · 6c684b18
      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>
      6c684b18
    • Marc G. Fournier's avatar
      Fixes: · ab22b348
      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>
      ab22b348
  19. 20 Jul, 1996 1 commit
    • Marc G. Fournier's avatar
      Fixes: · 94215d51
      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>
      94215d51
  20. 19 Jul, 1996 1 commit
    • Marc G. Fournier's avatar
      Fixes: · 20288400
      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>
      20288400
  21. 09 Jul, 1996 1 commit