- 30 9月, 1999 4 次提交
-
-
由 Jan Wieck 提交于
FOREIGN KEY triggers. Added pg_proc entries for all the new functions. Jan
-
由 Jan Wieck 提交于
Jan
-
由 Jan Wieck 提交于
Jan
-
由 Jan Wieck 提交于
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
-
- 26 9月, 1999 1 次提交
-
-
由 Tom Lane 提交于
Frankpitt, plus some improvements from yours truly. The simplifier depends on the proiscachable field of pg_proc to tell it whether a function is safe to pre-evaluate --- things like nextval() are not, for example. Update pg_proc.h to contain reasonable cacheability information; as of 6.5.* hardly any functions were marked cacheable. I may have erred too far in the other direction; see recent mail to pghackers for more info. This update does not force an initdb, exactly, but you won't see much benefit from the simplifier until you do one.
-
- 24 9月, 1999 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 07 9月, 1999 1 次提交
-
-
由 Tom Lane 提交于
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.
-
- 29 8月, 1999 1 次提交
-
-
由 Tom Lane 提交于
and 1370 (timestamp(datetime)). This does not force an initdb, exactly, but you won't see the effects of the bug fix until you do one. BTW, OID 1358 for timespan(time) is still broken: select timespan('21:11:26'::time); ERROR: No such function 'time_timespan' with the specified attributes But I couldn't figure out what it ought to be defined as, so I left it be.
-
- 09 8月, 1999 1 次提交
-
-
由 Tom Lane 提交于
-
- 01 8月, 1999 2 次提交
-
-
由 Tom Lane 提交于
neqsel now behave as per my suggestions in pghackers a few days ago. selectivity for < > <= >= should work OK for integral types as well, but still need work for nonintegral types. Since these routines have never actually executed before :-(, this may result in some significant changes in the optimizer's choices of execution plans. Let me know if you see any serious misbehavior. CAUTION: THESE CHANGES REQUIRE INITDB. pg_statistic table has changed.
-
由 Tom Lane 提交于
-
- 27 7月, 1999 1 次提交
-
-
由 Tom Lane 提交于
optimizer rather than parser. This has many advantages, such as not getting fooled by chance uses of operator names ~ and ~~ (the operators are identified by OID now), and not creating useless comparison operations in contexts where the comparisons will not actually be used as indexquals. The new code also recognizes exact-match LIKE and regex patterns, and produces an = indexqual instead of >= and <=. This change does NOT fix the problem with non-ASCII locales: the code still doesn't know how to generate an upper bound indexqual for non-ASCII collation order. But it's no worse than before, just the same deficiency in a different place... Also, dike out loc_restrictinfo fields in Plan nodes. These were doing nothing useful in the absence of 'expensive functions' optimization, and they took a considerable amount of processing to fill in.
-
- 21 7月, 1999 2 次提交
-
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
- 17 7月, 1999 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 16 7月, 1999 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 15 7月, 1999 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 14 7月, 1999 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 09 7月, 1999 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 26 5月, 1999 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 10 5月, 1999 2 次提交
-
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
real affect now.
-
- 09 5月, 1999 1 次提交
-
-
由 Tom Lane 提交于
-
- 04 5月, 1999 1 次提交
-
-
由 Bruce Momjian 提交于
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
-
- 20 4月, 1999 1 次提交
-
-
由 Tom Lane 提交于
pg_proc entries for array I/O routines besides the one detected by the original patcher. Tighten type_sanity regress test accordingly.
-
- 14 4月, 1999 1 次提交
-
-
由 Bruce Momjian 提交于
actually takes three. Please apply the following patch. Massimo
-
- 11 4月, 1999 1 次提交
-
-
由 Tom Lane 提交于
These were bogus selectivity-estimator links, like a '>' operator pointing to intltsel when it should use intgtsel.
-
- 08 4月, 1999 1 次提交
-
-
由 Tom Lane 提交于
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.
-
- 07 4月, 1999 1 次提交
-
-
由 Tom Lane 提交于
hashjoins. Extend opr_sanity regress test to help detect similar mistakes.
-
- 04 4月, 1999 1 次提交
-
-
由 Tom Lane 提交于
polygon rtree, circle rtree indexes.
-
- 29 3月, 1999 1 次提交
-
-
由 Tom Lane 提交于
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.
-
- 28 3月, 1999 3 次提交
- 26 3月, 1999 2 次提交
- 25 3月, 1999 1 次提交
-
-
由 Tom Lane 提交于
need not be bogus.
-
- 15 3月, 1999 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 14 3月, 1999 1 次提交
-
-
由 Bruce Momjian 提交于
I would like some feedback on what the hash function for the int8 hash function in the ./backend/access/hash/hashfunc.c should return. Also, could someone (maybe Tomas Lockhart?) look-over the patch and make sure the system table entries are correct? I've tried to research them as much as I could, but some of them are still not clear to me. Thanks, -Ryan
-
- 10 3月, 1999 1 次提交
-
-
由 Tom Lane 提交于
and pg_operator. The lone error in pg_operator was reported as a bug by Michael Reifenberger; the multiple errors in pg_proc would only have been noticed if one invoked the functions by name rather than using operator syntax. I guess few people do that.
-