When an acl item is added or updated the new entry is deleted if it has no
permissions and the acl array is shrinked. This is is done by decrementing
the number of items without updating the corresponding array size.
The array with the incorrect size is later read by pg_aclcheck and the entry
count is used to allocate a new array while the array size is used to copy
the old one. This causes a memory corruption and a backend crash.
This happens only to normal user as the administrator bypasses acl checks.
Massimo Dal Zotto
* Wrote max(date) and min(date) aggregates
* Wrote operator "-" for date; date - date yields number of days
difference
* Wrote operator+(date,int) and operator-(date,int); the int is the
number of days. Each operator returns a new date.
By: Tom Tromey <tromey@creche.cygnus.com>
In particular, no more compiled-in default for PGDATA or LIBDIR. Commands
that need them need either invocation options or environment variables.
PGPORT default is hardcoded as 5432, but overrideable with options or
environment variables.
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.
The comparison routines for text and char data type give incorrect results
if the input data contains characters greater than 127. As these routines
perform the comparison using signed char variables all character codes
greater than 127 are interpreted as less than 0. These codes are used to
encode the iso8859 char sets.
The other text-like data types seem to work as expected as they use unsigned
chars in comparisons.
Submitted by: Massimo Dal Zotto <dz@cs.unitn.it>
conditions are always met. The patch can be applied to any version
of Postgres95 from 1.02 to 1.05. After applying the patch, queries
using indices on bpchar and varchar fields should (hopefully ;-) )
always return the same tuple set regardless to the fact whether
indices are used or not.
Submitted by: Gerhard Reithofer <tbr_laa@AON.AT>
---
below my signature, there are a coupls of diffs and files in a shell
archive, which were needed to build postgres95 1.02 on Siemens Nixdorfs
MIPS based SINIX systems. Except for the compiler switches "-W0" and
"-LD-Blargedynsym" these diffs should also apply for other SVR4 based
systems. The changes in "Makefile.global" and "genbki.sh" can probably
be ignored (I needed gawk, to make the script run).
There is one bugfix thou. In "src/backend/parser/sysfunc.c" the
function in this file didn't honor the EUROPEAN_DATES ifdef.
---
Submitted by: Frank Ridderbusch <ridderbusch.pad@sni.de>
and found out that one of the patches is a show stopper for
compiling under a strict ansi package.
Please make sure the following fix makes it into the 1.02.1
release...
Thanks.
-Kurt
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>
Select queries with an isnull or notnull clause, like "select * where
somefield isnull", crash the backend if the table has at least one index.
If the indices are deleted the queries work again. Also the explain
command fail in the same way.
The is caused by a bug in subroutine of the optimizer which doesn't check
null values in the clauses.
Submitted by: Massimo Dal Zotto <dz@cs.unitn.it>
This is a patch to prevent an endless loop occuring in the Postgres backend
when a 'warning' error condition generates another warning error contition
in the handler code.
Submitted by: Chris Dunlop, <chris@onthe.net.au>
varchar.diff
------------
This patch was necessary for the OpenLink Postgres Database Agent.
I think this fixes a bug anyway.
The following query demonstrates this bug:
create table foo (bar varchar);
insert into foo values (''); -- no problem
select * from foo where bar = ''; -- fails
causes segmentation fault.
Thanks to: Salvador Ortiz Garcia, Robert Patrick, Paul 'Shag' Walmsley,
and James Cooper for finding and fixing the problem.