inclusion in pgsql. I have included a README which should be enough
to start using it, plus a BENCH file that describes some timings
I have done.
Please have a look at it, and if you think everything is OK, I
would like it seen included in the contrib-section of pgsql.
I don't think I will do any more work in this, but maybe it inspires
somebody else to improve on it.
Maarten Boekhold
now. Here some tested features, (examples included in the patch):
1.1) Subselects in the having clause 1.2) Double nested subselects
1.3) Subselects used in the where clause and in the having clause
simultaneously 1.4) Union Selects using having 1.5) Indexes
on the base relations are used correctly 1.6) Unallowed Queries
are prevented (e.g. qualifications in the
having clause that belong to the where clause) 1.7) Insert
into as select
2) Queries using the having clause on view relations also work
but there are some restrictions:
2.1) Create View as Select ... Having ...; using base tables in
the select 2.1.1) The Query rewrite system:
2.1.2) Why are only simple queries allowed against a view from 2.1)
? 2.2) Select ... from testview1, testview2, ... having...; 3) Bug
in ExecMergeJoin ??
Regards Stefan
of days --- it was emitting stuff like
REVOKE ALL on 'table' from PUBLIC; GRANT ALL on "table" to
"Public"; neither of which work. While I was at it I
cleaned up a few other things:
* \connect commands are issued only in -z mode. In this way,
reloading a pg_dump script made without -z will generate a simple
database wholly owned by the invoking user, rather than a mishmash
of tables owned by various people but lacking in access rights.
(Analogy: cp versus cp -p.)
* \connect commands are issued just before COPY FROM stdin commands;
without this, reloading a database containing non-world-writable
tables tended to fail because the COPY was not necessarily attempted
as the table owner.
* Redundant \connect commands are suppressed (each one costs a
backend launch, so...).
* Man page updated (-z wasn't ever documented).
The first two items were discussed in a pgsql-hackers thread around
6 May 98 ("An item for the TODO list: pg_dump and multiple table
owners") but no one had bothered to deal with 'em yet.
regards, tom lane
6.3.2 to compile (and run) on my Sparc Solaris 2.5.1 box. Details
below:
pgsql.sparc.patch-template: Adds -D__sparc__ and -D__sun__,
defintions which gcc does define, but Sun's cc does not. :(
pgsql.sparc.patch-makefile: Adds a define so that 'lorder'
is not used, as it is not found on my machine.
Ryan Kirkpatrick
in a more readable form. -- I am submitting the following patches
to the June 6, 1998 snapshot of PostgreSQL. These patches implement
a port of PostgreSQL to SCO UnixWare 7, and updates the Univel port
(UnixWare 2.x). The patched files, and the reason
for the patch are:
File Reason for the patch ---------------
---------------------------------------------------------------
src/backend/port/dynloader/unixware.c src/backend/port/dynloader/unixware.h
src/include/port/unixware.h src/makefiles/Makefile.unixware
src/template/unixware
Created for the UNIXWARE port.
src/include/port/univel.h
Modifed this file to work with the changes made to
s_lock.[ch].
src/backend/storage/buffer/s_lock.c src/include/storage/s_lock.h
Moved the UNIXWARE (and Univel) tas() function from
s_lock.c to s_lock.h. The UnixWare compiler asm
construct is treated as a macro and needs to be in
the s_lock.h file. I also reworked the tas()
function to correct some errors in the code.
src/include/version.h.in
The use of the ## operator with quoted strings in
the VERSION macro caused problems with the UnixWare
C compiler. I removed the ## operators since they
were not needed in this case. The macro expands
into a sequence of quoted strings that will be
concatenated by any ANSI C compiler.
src/config.guess
This script was modified to recognize SCO UnixWare
7.
src/configure src/configure.in
The configure script was modified to recognize SCO
UnixWare 7.
Billy G. Allie
NS32K machine I contributed. In any case, I now have postgresql-6.3
running again on NetBSD/pc532, a NS32532 machine. The following
changes are needed relative to the src directory. (It looks like
support was partially removed when the files were moved from the
src/backend/storage/.... tree to the src/include tree.)
If you need me to get a current development version of postgresql
for this change let me know. Also, let me know if this code needs
updating due to another code movement that deleted the old NS32K
support.
Thank you.
Phil Nelson
GCC, the inner "#if defined(__GNUC__)" can just be omitted in that
architecture's block.
The existing arrangement with an outer "#if defined(__GNUC__)"
doesn't have any obvious benefit, and it encourages missed cases
like this one.
BTW, I'd suggest making the definition of clear_lock for HPUX be
static const slock_t clear_lock = {{-1, -1, -1, -1}};
The extra braces are needed to suppress warnings from gcc, and
declaring it const just seems like good practice.
regards, tom lane
but as I don't have access to a sparc for testing I just did what
I could. I am guessing here, but please apply the following to your
pgsql and let me know what happens. Also, cd to src/storage/buffer
and do 'make s_lock_test' as well.
David Gould
requires manual editing of src/backend/port/getrusage.c, because
its substitute version of getrusage is #if'd out.
There is no good reason for that, because configure won't even
include the file into the Makefile unless the platform hasn't got
getrusage. Furthermore, we only have one working substitute version
of getrusage --- the alleged HPUX syscall-based code doesn't work.
(It causes a coredump because the syscall returns a struct rusage
that's much larger than the stub struct defined in
src/include/rusagestub.h.) The times()-based emulation works fine
on HPUX, however.
I propose, therefore, that getrusage.c should just unconditionally
compile the times-based version, and rely on configure to include
the file only if needed. This will be one less manual configuration
step on all platforms that need this code.
Patch attached.
Tom Lane.
Bruce Momjian