I have attached a patch to allow GROUP BY and/or ORDER BY function or
expressions. Note worthy items:
1. The expression or function need not be in the target list.
Example:
SELECT name FROM foo GROUP BY lower(name);
2. Simplified the grammar to use expressions only.
3. Cleaned up earlier patch in this area to make use of existing
utility functions.
3. Reduced some of the members in the SortGroupBy parse node. The
original data members were redundant with the new expression node.
(MUST do a "make clean" now)
4. Added a new parse node "JoinUsing". The JOIN USING clause was
overloading this SortGroupBy structure. With the afore mentioned
reduction of members, the two clauses lost all their commonality.
5. A bug still exist where, if a function or expression is GROUPed BY,
and an aggregate function does not include a attribute from the
expression or function, the backend crashes. (or something like
that) The bug pre-dates this patch. Example:
SELECT lower(a) AS lowcase, count(b) FROM foo GROUP BY lowcase;
*** BOOM ***
--Also when not in target list
SELECT count(b) FROM foo GROUP BY lower(a);
*** BOOM AGAIN ***
Allows the following query to succeed: "SELECT NULL ORDER BY 1;"
There are three or four cases in transformSortClause() and I had fixed
only one case for UNION. A second case is now fixed, in the same way; I
assigned INT4OID to the column type for the "won't actually happen"
sort. Didn't want to skip the code entirely, since the backend needs to
_try_ a sort to get the NULLs right. I'm not certain under what
circumstances the other cases are invoked and these are not yet
fixed up, though perhaps they don't need to be...
Adrian Hall reported a problem to me that snprintf() doesn't exist in, at
least, Solaris 2.5.1. We use it in backend/utils/adt/int8.c.
Add a check to configure so that we see if it exists or not, and, if not,
compile in snprintf.c from backend/port, which was taken from, and falls under
the same Berkeley license as us, the FreeBSD libc/stdio ...
Marc G. Fournier [Sun, 26 Jul 1998 04:31:41 +0000 (04:31 +0000)]
From: t-ishii@sra.co.jp
As Bruce mentioned, this is due to the conflict among changes we made.
Included patches should fix the problem(I changed all MB to
MULTIBYTE). Please let me know if you have further problem.
P.S. I did not include pathces to configure and gram.c to save the
file size(configure.in and gram.y modified).
Bruce Momjian [Sun, 26 Jul 1998 01:18:09 +0000 (01:18 +0000)]
Fix compile error. Make transaction/work optional on all transaction
statements. More cleanups of psql help. Fix for shift/reduce on
UNION in subselect.
Marc G. Fournier [Fri, 24 Jul 1998 03:32:46 +0000 (03:32 +0000)]
I really hope that I haven't missed anything in this one...
From: t-ishii@sra.co.jp
Attached are patches to enhance the multi-byte support. (patches are
against 7/18 snapshot)
* determine encoding at initdb/createdb rather than compile time
Now initdb/createdb has an option to specify the encoding. Also, I
modified the syntax of CREATE DATABASE to accept encoding option. See
README.mb for more details.
For this purpose I have added new column "encoding" to pg_database.
Also pg_attribute and pg_class are changed to catch up the
modification to pg_database. Actually I haved added pg_database_mb.h,
pg_attribute_mb.h and pg_class_mb.h. These are used only when MB is
enabled. The reason having separate files is I couldn't find a way to
use ifdef or whatever in those files. I have to admit it looks
ugly. No way.
* support for PGCLIENTENCODING when issuing COPY command
commands/copy.c modified.
* support for SQL92 syntax "SET NAMES"
See gram.y.
* support for LATIN2-5
* add UNICODE regression test case
* new test suite for MB
New directory test/mb added.
* clean up source files
Basic idea is to have MB's own subdirectory for easier maintenance.
These are include/mb and backend/utils/mb.
Bruce Momjian [Tue, 21 Jul 1998 04:17:30 +0000 (04:17 +0000)]
Theses buffer leaks are caused by indexes that are kept open between
calls. Outside a transaction, the backend detects them as buffer
leaks; it sends a NOTICE, and frees them. This sometimes cause a
segmentation fault (at least on Linux). These indexes are initialized
on the first lo_read/lo_write/lo_tell call, and (normally) closed
on a lo_close call. Thus the buffer leaks appear when lo direct
access functions are used, and not with lo_import/lo_export functions
(libpq version calls lo_close before ending the command, and the
backend version uses another path).
The included patches (against recent snapshot, and against 6.3.2)
cause indexes to be closed on transaction end (that is on explicit
'END' statment, or on command termination outside trasaction blocks),
thus preventing the buffer leaks while increasing performance inside
transactions. Some (all?) 'classic' memory leaks are also removed.
I hope it will be ok.
--- Pascal ANDRE, graduated from Ecole Centrale Paris andre@via.ecp.fr
Bruce Momjian [Sun, 19 Jul 1998 18:26:41 +0000 (18:26 +0000)]
I finally got the time to put together some stuff for fti for
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.
Bruce Momjian [Sun, 19 Jul 1998 05:49:26 +0000 (05:49 +0000)]
1) Queries using the having clause on base tables should work well
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 ??
Bruce Momjian [Sun, 19 Jul 1998 05:24:51 +0000 (05:24 +0000)]
pg_dump -z has gotten rather thoroughly broken in the last couple
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.
Bruce Momjian [Sun, 19 Jul 1998 04:30:04 +0000 (04:30 +0000)]
Attached are the three patches that were needed to get PostgreSQL
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.
Bruce Momjian [Sun, 19 Jul 1998 04:17:13 +0000 (04:17 +0000)]
My mailer munged the intro text in my last post. Here is the text
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.
Bruce Momjian [Sun, 19 Jul 1998 01:19:54 +0000 (01:19 +0000)]
Somewhere between 6.1 and 6.3 someone removed the support for the
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.
Bruce Momjian [Sat, 18 Jul 1998 14:51:10 +0000 (14:51 +0000)]
On architectures where we don't have any special inline code for
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
Bruce Momjian [Sat, 18 Jul 1998 14:38:12 +0000 (14:38 +0000)]
Thank you for testing and reporting this. It is my fault of course,
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.