than silently returning zero on some machines. Correct float8 regress test
to agree. Also fix pow() overflow/underflow check to work correctly on
HPUX.
mistakes in creating pg_operator table. NOTE: right now, this will
fail because of conflicting definitions for point @ path operator.
I trust we're gonna fix that.
for against a just updated CVS tree. It contains
Partial new rewrite system that handles subselects, view
aggregate columns, insert into select from view, updates
with set col = view-value and select rules restriction to
view definition.
Updates for rule/view backparsing utility functions to
handle subselects correct.
New system views pg_tables and pg_indexes (where you can
see the complete index definition in the latter one).
Enabling array references on query parameters.
Bugfix for functional index.
Little changes to system views pg_rules and pg_views.
The rule system isn't a release-stopper any longer.
But another stopper is that I don't know if the latest
changes to PL/pgSQL (not already in CVS) made it compile on
AIX. Still wait for some response from Dave.
Jan
here is the patch that includes PL/pgSQL into the build
(currently with make errors ignored) and adds a regression
test for it. A clean build and regression ran fine here.
Can you please apply it?
The tar should be extracted in /usr/local/src/pgsql and
creates the following files:
src/pl/Makefile
called by toplevel GNUmakefile and for now only calls
src/pl/plpgsql/Makefile
src/pl/plpgsql/Makefile
calls src/pl/plpgsql/src/Makefile (here the call to
make ignores build errors - this must be changed
later for the final release).
src/test/regress/input/install_plpgsql.source
SQL script installing PL/pgSQL language in regression
database. Will be modified by .../input/Makefile to
point to correct PGLIB directory where plpgsql.so
gets installed.
src/test/regress/output/install_plpgsql.source
expected output for installation script.
src/test/regress/sql/plpgsql.sql
the main regression test. It tests functions and
triggers written in PL/pgSQL including views that use
supportfunctions in this language.
src/test/regress/expected/plpgsql.out
the expected output for the above regression test.
make_plpgsql.diff
patch that adds some lines to
src/GNUmakefile.in
src/test/regress/expected/Makefile
src/test/regress/input/Makefile
src/test/regress/output/Makefile
src/test/regress/sql/Makefile
src/test/regress/sql/tests
test passes. Interestingly, the fix involves no changes or special
cases in the union test and actually removes a special case for the
numerology test. Thus, following the strategy outlined below is a
definite improvement over the previous situation.
Cheers,
Brook
>
> Please apply this HAVING regression patch.
> > My bad. It is caused by a known bug having to do with GROUP BY.
It ain't$
> > nothing to do with HAVING. For some reason the bug went away for a
while, $
> > script. It must have, because that is how I created the expected
file. :(
> >
> > A patch to the regression will be forthcoming.
>
the following to regress/sql/tests.
If applying by hand note that the setup_... must run before
the run_... (that I splitted these two was due to the errors
that occured when creating rules and using them then in the
same session - I'll post another fix for this later).
BTW: the regression tests sanity_checks and alter_table fail
now due to the remove of some indices and the oidint4 and
oidname types. At least expectes should be set to the current
results.
Thanks.
Jan
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 ***
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).
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.
I have implemented a framework of encoding translation between the
backend and the frontend. Also I have added a new variable setting
command:
SET CLIENT_ENCODING TO 'encoding';
Other features include:
Latin1 support more 8 bit cleaness
See doc/README.mb for more details. Note that the pacthes are
against May 30 snapshot.
Tatsuo Ishii
Attached to the mail is locale-patch.tar.gz. In the archive
there are:
file README.locale
short description
directory src/test/locale
test suite; currently only koi8-r tests, but the suite can be
easily extended
file locale.patch
the very patch; to apply: patch < locale.patch; should be applied
to postgres-6.3.2 (at least I created it with 6.3.2 without any
additional
patches)
Files touched by the patch: src/include/utils/builtins.h
src/backend/utils/adt/char.c src/backend/utils/adt/varchar.c
src/backend/utils/adt/varlena.c
Oleg
Bruce Momjian
Thomas G. Lockhart
Tom Lane
Marc G. Fournier