- 30 7月, 1999 1 次提交
-
-
由 Tom Lane 提交于
-
- 29 7月, 1999 6 次提交
-
-
由 Bruce Momjian 提交于
-
由 Tom Lane 提交于
so that Case works in WHERE join clauses. Temporary patch --- this routine is one of many that ought to be changed to use centralized expression-tree- walking logic.
-
由 Tom Lane 提交于
detected this omission before. Miscellaneous other cleanups.
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Tom Lane 提交于
IN and NOT IN operators. Rewrite grotty implementation of IN-list parsing ... look Ma, no global variable ...
-
- 28 7月, 1999 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 27 7月, 1999 4 次提交
-
-
由 Tom Lane 提交于
rels that the inner path needs to join to, but it was only checking for the first one. Failure could only have been observed with an OR-clause that mentions 3 or more tables, and then only if the bogus path was actually selected as cheapest ...
-
由 Tom Lane 提交于
be picked for one of the complex joins in rules test ... leading to a different output ordering ...
-
由 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.
-
由 Bruce Momjian 提交于
-
- 26 7月, 1999 3 次提交
-
-
由 Bruce Momjian 提交于
-
由 Tom Lane 提交于
to index_selectivity so that it can be handed an indexqual clause list rather than a bunch of assorted derivative data.
-
由 Tom Lane 提交于
The only place it was being used was as temporary storage in indxpath.c, and the logic was wrong: the same restrictinfo node could get chosen to carry the info for two different joins. Right fix is to return a second list of unjoined-relids parallel to the list of clause groups.
-
- 25 7月, 1999 1 次提交
-
-
由 Tom Lane 提交于
identified by Hiroshi (incorrect cost attributed to OR clauses after multiple passes through set_rest_selec()). I think the code was trying to allow selectivities of OR subclauses to be passed in from outside, but noplace was actually passing any useful data, and set_rest_selec() was passing wrong data. Restructure representation of "indexqual" in IndexPath nodes so that it is the same as for indxqual in completed IndexScan nodes: namely, a toplevel list with an entry for each pass of the index scan, having sublists that are implicitly-ANDed index qual conditions for that pass. You don't want to know what the old representation was :-( Improve documentation of OR-clause indexscan functions. Remove useless 'notclause' field from RestrictInfo nodes. (This might force an initdb for anyone who has stored rules containing RestrictInfos, but I do not think that RestrictInfo ever appears in completed plans.)
-
- 23 7月, 1999 3 次提交
-
-
由 Tom Lane 提交于
comments. This file was full of obsolete and just plain wrong commentary...
-
由 Tom Lane 提交于
invoked during exit from a standalone backend, leading to core dump. This is the cause of the recently reported initdb-time crash :-(. Sorry folks...
-
由 Bruce Momjian 提交于
-
- 22 7月, 1999 3 次提交
-
-
由 Thomas G. Lockhart 提交于
lisp.sgml is a placeholder for Eric Marsden's upcoming contribution. catalogs.sgml is not yet marked up or integrated. It should perhaps become an appendix.
-
由 Thomas G. Lockhart 提交于
ecpg reference page still needs formatting.
-
由 Tom Lane 提交于
unexpected loss of connection to frontend.
-
- 21 7月, 1999 7 次提交
-
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
the query string to handle any length, I discovered that under certain conditions, psql will core dump when handling long strings. Thus, the patch. It was caused by a buffer overrun, probably not noticeable in a lot of cases, but pretty noticeable in mine. Problem was caused by the fact that the length check is only performed after the check for a ; to get the end of the query and execute. Cheers... MikeA
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
- 20 7月, 1999 9 次提交
-
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Tom Lane 提交于
support, but which the grammar was accepting. Also, fix several bugs having to do with failure to copy fields up from a subselect to a select or insert node.
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
Massimo
-
- 19 7月, 1999 2 次提交
-
-
由 Bruce Momjian 提交于
-
由 Michael Meskes 提交于
-