1. Using 100 digits after decimal point on the default
make runtest.
2. Using 1000 digits after decimal point in a new target
make bigtest.
At the end of 'make runtest', a hint about the new bigtest is
printed.
Jan
"SYSTEM", and unpack the files in the uuencoded .tar.gz file at the end in
src/test/regress so that the int2, int4 and geometry tests pass on NetBSD/i386.
They just fail on different wording of error messages and eg printing "0"
rather than "-0". At a guess the same will be true for the other NetBSD ports,
but I can't test them.
Cheers,
Patrick
arrayfuncs.patch fixes a small bug in my previous patches for
arrays
array-regress.patch adds _bpchar and _varchar to regression tests
--
Massimo Dal Zotto
been applied. The patches are in the .tar.gz attachment at the end:
varchar-array.patch this patch adds support for arrays of bpchar() and
varchar(), which where always missing from postgres.
These datatypes can be used to replace the _char4,
_char8, etc., which were dropped some time ago.
block-size.patch this patch fixes many errors in the parser and other
program which happen with very large query statements
(> 8K) when using a page size larger than 8192.
This patch is needed if you want to submit queries
larger than 8K. Postgres supports tuples up to 32K
but you can't insert them because you can't submit
queries larger than 8K. My patch fixes this problem.
The patch also replaces all the occurrences of `8192'
and `1<<13' in the sources with the proper constants
defined in include files. You should now never find
8192 hardwired in C code, just to make code clearer.
--
Massimo Dal Zotto
the database encoding and the client encoding match the encoding expected
by the test. So, force both of them to be set from the MULTIBYTE
environment var. This allows regress tests to be run successfully in
multibyte environments other than the compiled-in default.
- change temp -> temp_bench ("temp" is now a reserved word)
- fix bugs in queries
- add -B 256 option to run the postgres command
(without this, postgres seems to fail with hashjoin)
in rules regression test, in order to eliminate bogus test 'failures'
that occur due to platform-dependent and join-implementation-dependent
ordering of tuples. I'm not sure that I got all of the SELECTs that need
ordering clauses --- we may need some more. But this takes care of the
diffs between my platform and Jan's.
Previously, dates falling within Unix system time range were run through
a call to localtime() to get the time zone, if it was not specified.
This had the effect that dates with DOMs which were larger than would be
valid for that month were "rotated" into the following months.
hashjoin's hashFunc() so that it does the right thing with pass-by-value
data types (the old code would always return 0 for int2 or char values,
which would work but would slow things down a lot). Extend opr_sanity
regress test to catch more kinds of errors.
There are two subdirectories (ISO8859-7 and koi8-to-win1251) containing
tests for Greek locale and server<=>client recoding feature (recently
submitted by Tatsuo Ishii <t-ishii@sra.co.jp>; we've debugged his patches
together in the field of Cyrillic support).
function is found in prosrc field of pg_proc, not proname. This allows
multiple aliases of a built-in to all be implemented as direct builtins,
without needing a level of indirection through an SQL function. Replace
existing SQL alias functions with builtin entries accordingly.
Save a few K by not storing string names of builtin functions in fmgr's
internal table (if you really want 'em, get 'em from pg_proc...).
Update opr_sanity with a few more cross-checks.
NetBSD/macppc
LinuxPPC
FreeBSD 2.2.6-RELEASE
All of them seem happy with the regression test. Note that, however,
compiling with optimization enabled on NetBSD/macppc causes an initdb
failure (other two platforms are ok). After checking the asm code, we
are suspecting that might be a compiler(egcs) bug.
Tatsuo Ishii
so remove them from MergeJoin node. Hack together a partial
solution for commuted mergejoin operators --- yesterday
a mergejoin int4 = int8 would crash if the planner decided to
commute it, today it works. The planner's representation of
mergejoins really needs a rewrite though.
Also, further testing of mergejoin ops in opr_sanity regress test.
Ok. I made patches replacing all of "#if FALSE" or "#if 0" to "#ifdef
NOT_USED" for current. I have tested these patches in that the
postgres binaries are identical.
rule system semantics by having Var nodes referenced across multiple
parsetrees when rules split them.
Added more tests to the rules regression test.
The code in question resulted from v6.3 based development and was
a little careless applied to the v6.5 source tree.
Jan
o allow to use Big5 (a Chinese encoding used in Taiwan) as a client
encoding. In this case the server side encoding should be EUC_TW
o add EUC_TW and Big5 test cases to the regression and the mb test
(contributed by Jonah Kuo)
o fix mistake in include/mb/pg_wchar.h. An encoding id for EUC_TW was
not correct (was 3 and now is 4)
o update documents (doc/README.mb and README.mb.jp)
o update psql helpfile (bin/psql/psqlHelp.h)
--
Tatsuo Ishii
t-ishii@sra.co.jp
was causing it not to detect out-of-range float values, as evidenced by
failure of float8 regression test. I corrected that logic and also
modified expected float8 results to account for new error message
generated for out-of-range inputs.
6.4.1. Here is the list:
- The type int8 now works. In fact, the bug(s) were in
src/backend/port/snprintf.c, so int8 is probably broken in every platform
that hasn't a native snprintf/vsnprintf. The type itself worked as
expected, only the output was wrong. Anyway, this patch should be checked
in other platforms.
- The regression tests for int2 and int4, which were broken due to
differences in the error messages, are fixed.
- The regression test for float8, which was broken in the reference
platform, is also fixed. I don't know if the new file (float8-OSF1.out)
will work on other platforms, but it might be worth to try it.
- Two new template files are provided (alpha_cc, which includes
optimization, and alpha_gcc), and src/templates/.similar is updated
accordingly. src/templates/alpha should be removed from the distribution.
*IMPORTANT NOTE*: I don't know if you can use gcc to compile postgres;
I've written the alpha_gcc file because alpha_cc has some flags that are
specific to DEC C.
- There is a (very basic) Digital Unix specific FAQ in
doc/FAQ_DigitalUnix.
--
-------------------------------------------------------------------
Pedro José Lobo Perea Tel: +34 91 336 78 19
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
src/test/regess/sql/junkfilter.sql -- SQL for
regression test src/test/regess/expected/junkfilter.out --
Expected output SQL for regression test
David Hartwig
Add additional tests in strings for conversions of the "name" data type.
Test SQL92 string functions such as SUBSTRING() and POSITION().
Fix geometry tests to reflect code fixed by Gautam.
Update error messages.
Everything (except of course random) passes on my netbsd box except int2,
int4, oidint2, and oidint4; all fail because of error message differences.
Below are some patches to the expectations to correct the problem by creating
*-NetBSD.out files.
Hi, here are patches I promised (against 6.3.2):
* character_length(), position(), substring() are now aware of
multi-byte characters
* add octet_length()
* add --with-mb option to configure
* new regression tests for EUC_KR
(contributed by "Soonmyung. Hong" <hong@lunaris.hanmesoft.co.kr>)
* add some test cases to the EUC_JP regression test
* fix problem in regress/regress.sh in case of System V
* fix toupper(), tolower() to handle 8bit chars
note that:
o patches for both configure.in and configure are
included. maybe the one for configure is not necessary.
o pg_proc.h was modified to add octet_length(). I used OIDs
(1374-1379) for that. Please let me know if these numbers are not
appropriate.
1. Remove the char2, char4, char8 and char16 types from postgresql
2. Change references of char16 to name in the regression tests.
3. Rename the char16.sql regression test to name.sql. 4. Modify
the regression test scripts and outputs to match up.
Might require new regression.{SYSTEM} files...
Darren King
Included are patches intended for allowing PostgreSQL to handle
multi-byte charachter sets such as EUC(Extende Unix Code), Unicode and
Mule internal code. With the MB patch you can use multi-byte character
sets in regexp and LIKE. The encoding system chosen is determined at
the compile time.
To enable the MB extension, you need to define a variable "MB" in
Makefile.global or in Makefile.custom. For further information please
take a look at README.mb under doc directory.
(Note that unlike "jp patch" I do not use modified GNU regexp any
more. I changed Henry Spencer's regexp coming with PostgreSQL.)
Included are patches intended for allowing PostgreSQL to handle
multi-byte charachter sets such as EUC(Extende Unix Code), Unicode and
Mule internal code. With the MB patch you can use multi-byte character
sets in regexp and LIKE. The encoding system chosen is determined at
the compile time.
To enable the MB extension, you need to define a variable "MB" in
Makefile.global or in Makefile.custom. For further information please
take a look at README.mb under doc directory.
(Note that unlike "jp patch" I do not use modified GNU regexp any
more. I changed Henry Spencer's regexp coming with PostgreSQL.)
I thought it would be a good idea to ensure that the new view
permission model will not get broken by subsequent
fixes/changes. So I wrote a little regression test for it.
There is an ugly thing in this regression test. It creates
temporary a test user that is required for the tests. The
user is removed at the end of the test, but if sometimes the
regression suite is aborted or crashes exactly here, the test
user will lay around in the pg_shadow. Don't have a clue how
to get around.
Enclosed is the regression.diffs file from running the Feb 21st
snapshot regression tests for inclusion in src/test/regression
as regression.Aix41. Appears to be standard differences to me,
error messages, fp accuracy and times off by an hour due to PST
vs PDT.
if an operating specific expected file exists, use that for the comparison.
This allows for "legit" differences between results, like the "Result too
large" message vs "Math result not representable" ...
Also, have the failed diffs get output to regression.diffs so that its easy to
view those tests that failed
Jan Wieck
Tom Lane
Bruce Momjian
Tatsuo Ishii
Thomas G. Lockhart
Marc G. Fournier
Vadim B. Mikheev