interpret a column name as an output column alias (targetlist AS name),
ather than a real column name as it ought to. According to the spec,
only ORDER BY should look at output column names. I left in GROUP BY's
willingness to use an output column number ('GROUP BY 2'), even though
this is also contrary to the spec --- again, only ORDER BY is supposed
to accept that. But there is no possible reason to want to GROUP BY
an integer constant, so keeping this old behavior won't break any
SQL-compliant queries. DISTINCT ON will behave the same as GROUP BY.
Change numerology regress test, which depended on the incorrect
behavior.
erroneous expected output for RESET DateStyle: should be ISO now.
Fix run_check.sh so that test postmaster is started with PGDATESTYLE=ISO,
else the horology test won't pass.
selectivity functions and make the r-tree operators use them. The
estimation functions themselves are just stubs, unfortunately, but
perhaps someday someone will make them compute realistic estimates.
Change pg_am so that the optimizer can reliably tell the difference
between ordered and unordered indexes --- before it would think that
an r-tree index can be scanned in '<<' order, which is not right AFAIK.
Repair broken negator links for network_sup and related ops.
Initdb forced. This might be my last initdb force for 7.0 ... hope so
anyway ...
Implement "date/time grand unification".
Transform datetime and timespan into timestamp and interval.
Deprecate datetime and timespan, though translate to new types in gram.y.
Transform all datetime and timespan catalog entries into new types.
Make "INTERVAL" reserved word allowed as a column identifier in gram.y.
Remove dt.h, dt.c files, and retarget datetime.h, datetime.c as utility
routines for all date/time types.
date.{h,c} now deals with date, time types.
timestamp.{h,c} now deals with timestamp, interval types.
nabstime.{h,c} now deals with abstime, reltime, tinterval types.
Make NUMERIC a known native type for purposes of type coersion. Not tested.
accesses versus sequential accesses, a (very crude) estimate of the
effects of caching on random page accesses, and cost to evaluate WHERE-
clause expressions. Export critical parameters for this model as SET
variables. Also, create SET variables for the planner's enable flags
(enable_seqscan, enable_indexscan, etc) so that these can be controlled
more conveniently than via PGOPTIONS.
Planner now estimates both startup cost (cost before retrieving
first tuple) and total cost of each path, so it can optimize queries
with LIMIT on a reasonable basis by interpolating between these costs.
Same facility is a win for EXISTS(...) subqueries and some other cases.
Redesign pathkey representation to achieve a major speedup in planning
(I saw as much as 5X on a 10-way join); also minor changes in planner
to reduce memory consumption by recycling discarded Path nodes and
not constructing unnecessary lists.
Minor cleanups to display more-plausible costs in some cases in
EXPLAIN output.
Initdb forced by change in interface to index cost estimation
functions.
regression tests so I prepared a set of expected
files to make things look OK.
There's also a file to account for minor variations
in the geopmetry output and a resultmap patch to
pull them all together.
With these changes PostgreSQL, from CVS, builds and
regression tests (runcheck) cleanly.
Keith Parks.
Initdb help correction
Changed end/abort to commit/rollback and changed related notices
Commented out way old printing functions in libpq
Fixed a typo in alter table / alter column
SELECT DISTINCT ON (expr [, expr ...]) targetlist ...
and there is a check to make sure that the user didn't specify an ORDER BY
that's incompatible with the DISTINCT operation.
Reimplement nodeUnique and nodeGroup to use the proper datatype-specific
equality function for each column being compared --- they used to do
bitwise comparisons or convert the data to text strings and strcmp().
(To add insult to injury, they'd look up the conversion functions once
for each tuple...) Parse/plan representation of DISTINCT is now a list
of SortClause nodes.
initdb forced by querytree change...
Instead of hard-wiring one result file per platform, there is a map file
'resultmap' that says which one to use --- a lot like template/.similar.
I have only created entries in resultmap for my own platform (HPUX) so
far; feel free to add lines for other platforms.
which is broken in some weird way that I don't understand. I think it
may be exposing a bug in the new psql --- for one thing, I get different
results when I run psql by hand than the regress script gets. What
the heck???
mentioned in FROM but not elsewhere in the query: such tables should be
joined over anyway. Aside from being more standards-compliant, this allows
removal of some very ugly hacks for COUNT(*) processing. Also, allow
HAVING clause without aggregate functions, since SQL does. Clean up
CREATE RULE statement-list syntax the same way Bruce just fixed the
main stmtmulti production.
CAUTION: addition of a field to RangeTblEntry nodes breaks stored rules;
you will have to initdb if you have any rules.
they have no hardwired limit on the length of a rule's text. Fix a couple
of minor bugs in passing --- deparsed UPDATE queries didn't have quotes
around relation name, and quotes and backslashes in constant values weren't
backslash-quoted.
Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands.
TODO:
Generic builtin trigger procedures
Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE
Support of new trigger type in pg_dump
Swapping of huge # of events to disk
Jan
before comparison; if fields being joined are different widths then hashing
will yield wrong answer. Also, remove hashjoinable mark from all uses of
array_eq, because array structures may have padding bytes between elements
and the pad bytes are of uncertain content. This could be revisited if
array code is cleaned up.
Modify opr_sanity regress test to complain if array_eq operator is marked
hashjoinable.
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
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.
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.
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
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.
>
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 ***
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
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.)
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.
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
Subject: [PATCHES] Re: [PORTS] AIX 6.1 fixes...
Here are the patches for the two things that wouldn't make it thru the AIX
compiler. The geo_ops.c change is harmless I believe. The nbtcompare.c patch
fixes me, but I don't know about any other ports. Maybe wait on that one
until Vadim decides what to do about the unsigned vs signed chars varlena
issue.
Subject: [PATCHES] Patches for boolean, timespan and reltime regression tests.
Hi All,
Here are a couple of patches to the regression tests to introduce
some specific ordering to the results.
I've only made changes to the queries that were exhibiting differences
on my regression runs.
This will also have the side effect of testing the ordering code for
the boolean and some of the time types.
the DROP TABLE calls from the destroy.sql file to the 'types' .sql files,
so that they are self-contained
btree_index, hash_index and misc all fail as there seems to be missing
a 'misc.out' expected file...have asked Thomas for one...
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
Tom Lane
Thomas G. Lockhart
Bruce Momjian
Peter Eisentraut
Tatsuo Ishii
Jan Wieck
Marc G. Fournier
Vadim B. Mikheev