I put some extra checks to make sure a query was a good candidate for
rewrite into a UNION. Besides the existing checks:
1. Make sure the AND/OR tree was rectangular. ( i.e. 3 X 4 or 10 X
3)
2. Only one table.
3. Must have an AND dimension.
4. At least 9 OP expressions total
Also cleaned up and commented.
[AC_MSG_RESULT(yes) AC_DEFINE(HAVE_LONG_INT_64)],
this line produces something like:
echo "$ac_t""yes" 1>&6 cat >> confdefs.h <<\EOF
and would append garbage "yes cat" to confdefs.h. Of course the
result confdefs.h is not syntactically correct therefore following
tests using confdefs.h would all fail. To avoid the problem, we
could switch the order of AC_MSG_RESULT and AC_DEFINE (see attached
patch). This happend on my LinuxPPC box.
Tatsuo Ishii t-ishii@sra.co.jp
patch is applied:
Rewrite rules on relation level work fine now.
Event qualifications on insert/update/delete rules work
fine now.
I added the new keyword OLD to reference the CURRENT
tuple. CURRENT will be removed in 6.5.
Update rules can reference NEW and OLD in the rule
qualification and the actions.
Insert/update/delete rules on views can be established to
let them behave like real tables.
For insert/update/delete rules multiple actions are
supported now. The actions can also be surrounded by
parantheses to make psql happy. Multiple actions are
required if update to a view requires updates to multiple
tables.
Regular users are permitted to create/drop rules on
tables they have RULE permissions for
(DefineQueryRewrite() is now able to get around the
access restrictions on pg_rewrite). This enables view
creation for regular users too. This required an extra
boolean parameter to pg_parse_and_plan() that tells to
set skipAcl on all rangetable entries of the resulting
queries. There is a new function
pg_exec_query_acl_override() that could be used by
backend utilities to use this facility.
All rule actions (not only views) inherit the permissions
of the event relations owner. Sample: User A creates
tables T1 and T2, creates rules that log
INSERT/UPDATE/DELETE on T1 in T2 (like in the regression
tests for rules I created) and grants ALL but RULE on T1
to user B. User B can now fully access T1 and the
logging happens in T2. But user B cannot access T2 at
all, only the rule actions can. And due to missing RULE
permissions on T1, user B cannot disable logging.
Rules on the attribute level are disabled (they don't
work properly and since regular users are now permitted
to create rules I decided to disable them).
Rules on select must have exactly one action that is a
select (so select rules must be a view definition).
UPDATE NEW/OLD rules are disabled (still broken, but
triggers can do it).
There are two new system views (pg_rule and pg_view) that
show the definition of the rules or views so the db admin
can see what the users do. They use two new functions
pg_get_ruledef() and pg_get_viewdef() that are builtins.
The functions pg_get_ruledef() and pg_get_viewdef() could
be used to implement rule and view support in pg_dump.
PostgreSQL is now the only database system I know, that
has rewrite rules on the query level. All others (where I
found a rule statement at all) use stored database
procedures or the like (triggers as we call them) for
active rules (as some call them).
Future of the rule system:
The now disabled parts of the rule system (attribute
level, multiple actions on select and update new stuff)
require a complete new rewrite handler from scratch. The
old one is too badly wired up.
After 6.4 I'll start to work on a new rewrite handler,
that fully supports the attribute level rules, multiple
actions on select and update new. This will be available
for 6.5 so we get full rewrite rule capabilities.
Jan
no longer returns buffer pointer, can be gotten from scan;
descriptor; bootstrap can create multi-key indexes;
pg_procname index now is multi-key index; oidint2, oidint4, oidname
are gone (must be removed from regression tests); use System Cache
rather than sequential scan in many places; heap_modifytuple no
longer takes buffer parameter; remove unused buffer parameter in
a few other functions; oid8 is not index-able; remove some use of
single-character variable names; cleanup Buffer variables usage
and scan descriptor looping; cleaned up allocation and freeing of
tuples; 18k lines of diff;
indices for restriction clauses containing a constant.
Note that if an index does not match directly (usually because the types
on both side of the clause don't match), and if a binary-compatible index
is identified, then the operator function will be replaced by a new
one. Should not be a problem, but be sure that if types are listed as
being binary compatible (in parse_coerce.h) then the comparison functions
are also binary-compatible, giving equivalent results.
Everyone using an [NOT] EXISTS subquery will have noticed that
already.
The bug is in "subselect.c" in the function "SS_process_sublinks()".
Here the whole function as it *SHOULD BE*:
Stephan
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
1. Removes the unnecessary "#define AbcRegProcedure 123"'s from
pg_proc.h.
2. Changes those #defines to use the names already defined in
fmgr.h.
3. Forces the make of fmgr.h in backend/Makefile instead of having
it
made as a dependency in access/common/Makefile *hack*hack*hack*
4. Rearranged the #includes to a less helter-skelter arrangement,
also
changing <file.h> to "file.h" to signify a non-system header.
5. Removed "pg_proc.h" from files where its only purpose was for
the
#defines removed in item #1.
6. Added "fmgr.h" to each file changed for completeness sake.
Turns out that #6 was not necessary for some files because fmgr.h
was being included in a roundabout way SIX levels deep by the first
include.
"access/genam.h"
->"access/relscan.h"
->"utils/rel.h"
->"access/strat.h"
->"access/skey.h"
->"fmgr.h"
So adding fmgr.h really didn't add anything to the compile, hopefully
just made it clearer to the programmer.
S Darren.
Attached you'll find a (big) patch that fixes make dep and make
depend in all Makefiles where I found it to be appropriate.
It also removes the dependency in Makefile.global for NAMEDATALEN
and OIDNAMELEN by making backend/catalog/genbki.sh and bin/initdb/initdb.sh
a little smarter.
This no longer requires initdb.sh that is turned into initdb with
a sed script when installing Postgres, hence initdb.sh should be
renamed to initdb (after the patch has been applied :-) )
This patch is against the 6.3 sources, as it took a while to
complete.
Please review and apply,
Cheers,
Jeroen van Vianen
yyerror ones from bison. It also includes a few 'enhancements' to
the C programming style (which are, of course, personal).
The other patch removes the compilation of backend/lib/qsort.c, as
qsort() is a standard function in stdlib.h and can be used any
where else (and it is). It was only used in
backend/optimizer/geqo/geqo_pool.c, backend/optimizer/path/predmig.c,
and backend/storage/page/bufpage.c
> > Some or all of these changes might not be appropriate for v6.3,
since we > > are in beta testing and since they do not affect the
current functionality. > > For those cases, how about submitting
patches based on the final v6.3 > > release?
There's more to come. Please review these patches. I ran the
regression tests and they only failed where this was expected
(random, geo, etc).
Cheers,
Jeroen
sequential scans! (I think it will also work with hash, index, etc
but I did not check it out! I made some High level changes which
should work for all access methods, but maybe I'm wrong. Please
let me know.)
Now it is possible to make queries like:
select s.sname, max(p.pid), min(p.pid) from part p, supplier s
where s.sid=p.sid group by s.sname having max(pid)=6 and min(pid)=1
or avg(pid)=4;
Having does not work yet for queries that contain a subselect
statement in the Having clause, I'll try to fix this in the next
days.
If there are some bugs, please let me know, I'll start to read the
mailinglists now!
Now here is the patch against the original 6.3 version (no snapshot!!):
Stefan
of some global variables to support subselects and calls union_planner().
Calls to SS_replace_correlation_vars() and SS_process_sublinks() in
query_planner() before planning.
Get rid of #ifdef INDEXSCAN_PATCH in createplan.c.
varchar length.
Cleans up code so attlen is always length.
Removed varchar() hack added earlier.
Will fix bug in selecting varchar() fields, and varchar() can be
variable length.
Patch by: wieck@sapserv.debis.de (Jan Wieck)
One of the design rules of PostgreSQL is extensibility. And
to follow this rule means (at least for me) that there should
not only be a builtin PL. Instead I would prefer a defined
interface for PL implemetations.
Pass List* of Aggregs into executor, and create needed array there.
No longer need to double-processs Aggregs with second copy in Query.
Fix crash when doing:
select sum(x+1) from test where 1 > 0;
==========================================
What follows is a set of diffs that cleans up the usage of BLCKSZ.
As a side effect, the person compiling the code can change the
value of BLCKSZ _at_their_own_risk_. By that, I mean that I've
tried it here at 4096 and 16384 with no ill-effects. A value
of 4096 _shouldn't_ affect much as far as the kernel/file system
goes, but making it bigger than 8192 can have severe consequences
if you don't know what you're doing. 16394 worked for me, _BUT_
when I went to 32768 and did an initdb, the SCSI driver broke and
the partition that I was running under went to hell in a hand
basket. Had to reboot and do a good bit of fsck'ing to fix things up.
The patch can be safely applied though. Just leave BLCKSZ = 8192
and everything is as before. It basically only cleans up all of the
references to BLCKSZ in the code.
If this patch is applied, a comment in the config.h file though above
the BLCKSZ define with warning about monkeying around with it would
be a good idea.
Darren darrenk@insightdist.com
(Also cleans up some of the #includes in files referencing BLCKSZ.)
==========================================
Makefile.global.
End result, if all goes well, should allow for much easier porting, since
there will no longer be a concept of a "port". Most, if not everything,
*should* be determined by configure, or by the compiler itself. Still
work to be done though :)
Subject: [PORTS] Patches for Irix 6.4
I have worked out how to compile PostgreSQL on Irix 6.4 using the -n32 compiler
mode and version 7.1 of the C compiler. (The n32 compiler use 32 bits
addressing,
but allows access to all the instructions in the MIPS4 instruction set.)
There were several problems:
1) The ld command is not referenced as a macro in all the Makefiles. On
this platform, you have to include -n32 on all the ld commands. Makefiles
were changed as needed.
3) Lots of warnings are generated from the compiler. Since the regression
tests worked OK, I didn't attempt to fix them. If anyone wants the compilation
log, please let me know, and I'll email it to you.
The version of postgresql was 970602. Here is Makefile.custom:
CUSTOM_COPT = -O2 -n32
MK_NO_LORDER = 1
LD = ld -n32
CC += -n32
Subject: [HACKERS] src.original/./backend/lib/fstack.c
Another change I suggested. I bracket an unused function and add a
return to quiet the compiler. In addition I added an internal
consistency check.
Subject: [HACKERS] backend/optimizer/geqo/geqo_erx.c
I sent these changes in with a bunch of others. Some were folded in but
others, like these, were not. I am not sure why so I am resending this
to the developers list by itself for discussion.
The readon why I suggest these changes is that the compiler can't tell
that minimum_count is initialized before it is used. The tests that I
add in here will cause an immediate error if it doesn't. As the comments
below suggest, if it is 100% guaranteed that the variable will always
be initialized then how this is so should be commented here. I don't
know how much strain the actual test puts on the performance but if it
isn't too much then maybe leave it in for absolute safety anyway.
There are also a few returns just to stop warnings.
for join-relations. Sizes already computed by
prune_rel_paths():compute_joinrel_size().
joinrels.c:
< if ( _use_right_sided_plans_ )
---
> if ( _use_right_sided_plans_ &&
> length (outer_rel->relids) > 1 )
- r_plans are useful when outer_rel is join-relation... It
decreases the size of search space...
nestloop's join clauses doesn't work in some cases:
* 1. fix_indxqual_references may change varattno-s in
* inner_indxqual;
* 2. clauses may be commuted
Subject: Re: [HACKERS] GEQO and views (rules)
Oke, this was caused by a classic bug :-/
I thougth, root->base_relation_list_ could be
represented as relid string 1-2-3-4- etc.
Instead, in case of views, the count of relids doesn't start with "1" but
maybe 4-5-6- etc . :-(
GEQO patch follows ... views are now all right.
2. PageWeights are variables now.
3. Fixed using ceil((double)selec*indextuples) as estimation
for expected heap pages: ceil((double)selec*relpages) now.
use sum(npages)/((nkeys == 1) ? 1 : nkeys + 1) as expected index page
estimation for multi-key quals - instead of sum(npages).
In old code npages for x > 10 and x < 20 is twice as for x > 10 - cool ?
FreeBSD
The Makefile(s) have all been cleaned up such that there is a single
LDFLAGS vs LD_ADD or LDADD or LDFLAGS or LDFLAGS_BE. The Makefile(s)
should be alot more straightforward then they were before...and
consistent
Subject: [HACKERS] Aggregate function patches
Here are the aggregate function patches I originally sent in last December.
They fix sum() and avg() behavior for ints and floats when NULL values are
involved.
I was waiting to resubmit these until I had a chance to write a v6.0->v6.1
database upgrade script to ensure that existing v6.0 databases which have
not been reloaded for v6.1 do no break with the new aggregate behavior.
These scripts are included below. It's OK with me if someone wants to do
something different with the upgrade strategy, but something like this
was discussed a few weeks ago.
Also, there were a couple of small items which cropped up in doing a clean
install of 970403 (actually 970402 + 970403 changes since the full 970403
tar file appears to be damaged or at least suspect). They are the first
two patches below and can be omitted if desired (although I think they
aren't dangerous :).
Subject: [HACKERS] locale patches !
Hi there,
here are little patches to get Postgres 6.1 works with locale stuff.
This is a patch against 970402.tar.gz, there are no problem to apply them
by hand to 6.0 release. Collate stuff tested about 1-2 months in real
working database but I'm sure there must be no problem. US hackers
could vote against locale implementation ( locale for sure will affect to
speed of postgres ), so I introduce variable USE_LOCALE which
controls locale stuff. Non-US users now could use ~* operator
for searching and <order by> for strings with nation alphabet.
Please, don't forget, as I did first time, to set environment variable
LC_CTYPE and LC_COLLATE because backend get locale information from them.
I start postmaster from a little script, assuming that shell is Bash shell
it looks like:
#!/bin/sh
export LC_CTYPE=koi8-r
export LC_COLLATE=koi8-r
postmaster -B 1024 -S -D/usr/local/pgsql/data/ -o '-Fe'
> Please apply them to the direcory "backend/optimizer/geqo".
> Two new files with different crossover techniques are included.
> Standard procedure is optimization by means of "geqo_erx.c"
> (Edge Recombination Crossover).
From: "Martin S. Utesch" <utesch@aut.tu-freiberg.de>
Subject: [HACKERS] linux/alpha patches
These patches lay the groundwork for a Linux/Alpha port. The port doesn't
actually work unless you tweak the linker to put all the pointers in the
first 32 bits of the address space, but it's at least a start. It
implements the test-and-set instruction in Alpha assembly, and also fixes
a lot of pointer-to-integer conversions, which is probably good anyway.
Subject: [HACKERS] linux/alpha patches
These patches lay the groundwork for a Linux/Alpha port. The port doesn't
actually work unless you tweak the linker to put all the pointers in the
first 32 bits of the address space, but it's at least a start. It
implements the test-and-set instruction in Alpha assembly, and also fixes
a lot of pointer-to-integer conversions, which is probably good anyway.
2. IndexScanableOperand now uses match_indexkey_operand
instead of equal_indexkey_var (if we have some index on attribute X
then we shouldn't use it for 'where some_func(X) OP CONST').
/usr/include/limits.h (which quiets the costsize.c warnings)...under
FreeBSD, /usr/include/limits.h *includes* machine/limits.h, while under
Solaris, there is no such things as /usr/include/machine...
Problem with Solaris pointed out by Mark Wahl
The problem is that the function arguments are not considered as possible key
candidates for index scan and so only a sequential scan is possible inside
the body of a function. I have therefore made some patches to the optimizer
so that indices are now used also by functions. I have also moved the plan
debug message from pg_eval to pg_plan so that it is printed also for plans
genereated for function execution. I had also to add an index rescan to the
executor because it ignored the parameters set in the execution state, they
were flagged as runtime variables in ExecInitIndexScan but then never used
by the executor so that the scan were always done with any key=1. Very odd.
This means that an index rescan is now done twice for each function execution
which uses an index, the first time when the index scan is initialized and
the second when the actual function arguments are finally available for the
execution. I don't know what is the cost of an double index scan but I
suppose it is anyway less than the cost of a full sequential scan, at leat
for large tables. This is my patch, you must also add -DINDEXSCAN_PATCH in
Makefile.global to enable the changes.
Submitted by: Massimo Dal Zotto <dz@cs.unitn.it>
Select queries with an isnull or notnull clause, like "select * where
somefield isnull", crash the backend if the table has at least one index.
If the indices are deleted the queries work again. Also the explain
command fail in the same way.
The is caused by a bug in subroutine of the optimizer which doesn't check
null values in the clauses.
Submitted by: Massimo Dal Zotto <dz@cs.unitn.it>
Bruce Momjian
Thomas G. Lockhart
Vadim B. Mikheev
Tom Lane
Marc G. Fournier
PostgreSQL Daemon
Bryan Henderson