- 05 12月, 2002 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 02 12月, 2002 1 次提交
-
-
由 Tom Lane 提交于
well as function calls. This is needed for cases where the planner has constant-folded or inlined the original function call. Possibly we should back-patch this change into 7.3 branch as well.
-
- 01 12月, 2002 1 次提交
-
-
由 Tom Lane 提交于
logic, dissuade planner from thinking that 'x IS DISTINCT FROM 42' may be optimized into 'x = 42' (!!), cause dependency on = operator to be recorded correctly, minor other improvements.
-
- 30 11月, 2002 4 次提交
-
-
由 Tom Lane 提交于
cost into account while planning.
-
由 Tom Lane 提交于
instead of only one. This should speed up planning (only one hash path to consider for a given pair of relations) as well as allow more effective hashing, when there are multiple hashable joinclauses.
-
由 Tom Lane 提交于
operations: make sure we use operators that are compatible, as determined by a mergejoin link in pg_operator. Also, add code to planner to ensure we don't try to use hashed grouping when the grouping operators aren't marked hashable.
-
由 Tom Lane 提交于
-
- 26 11月, 2002 2 次提交
- 23 11月, 2002 2 次提交
-
-
由 Bruce Momjian 提交于
-hackers a couple days ago. Notes/caveats: - added regression tests for the new functionality, all regression tests pass on my machine - added pg_dump support - updated PL/PgSQL to support per-statement triggers; didn't look at the other procedural languages. - there's (even) more code duplication in trigger.c than there was previously. Any suggestions on how to refactor the ExecXXXTriggers() functions to reuse more code would be welcome -- I took a brief look at it, but couldn't see an easy way to do it (there are several subtly-different versions of the code in question) - updated the documentation. I also took the liberty of removing a big chunk of duplicated syntax documentation in the Programmer's Guide on triggers, and moving that information to the CREATE TRIGGER reference page. - I also included some spelling fixes and similar small cleanups I noticed while making the changes. If you'd like me to split those into a separate patch, let me know. Neil Conway
-
由 Tom Lane 提交于
one more row from the subplan than the COUNT would appear to require. This costs a little more logic but a number of people have complained about the old implementation.
-
- 20 11月, 2002 1 次提交
-
-
由 Tom Lane 提交于
of groups produced by GROUP BY. This improves the accuracy of planning estimates for grouped subselects, and is needed to check whether a hashed aggregation plan risks memory overflow.
-
- 15 11月, 2002 1 次提交
-
-
由 Bruce Momjian 提交于
Rod Taylor
-
- 13 11月, 2002 2 次提交
-
-
由 Bruce Momjian 提交于
of cursor.
-
由 Bruce Momjian 提交于
-
- 12 11月, 2002 1 次提交
-
-
由 Tom Lane 提交于
before commit, not after :-( --- the original coding is not only unsafe if an error occurs while it's processing, but it generates an invalid sequence of WAL entries. Resurrect 7.2 logic for deleting items when no longer needed. Use an enum instead of random macros. Editorialize on names used for routines and constants. Teach backend/nodes routines about new field in CreateTable struct. Add a regression test.
-
- 11 11月, 2002 1 次提交
-
-
由 Bruce Momjian 提交于
to MemSet is a performance boost.
-
- 10 11月, 2002 2 次提交
-
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
for temp tables. Gavin Sherry
-
- 07 11月, 2002 1 次提交
-
-
由 Tom Lane 提交于
hashed aggregation, but there's not yet planner support for it.
-
- 06 11月, 2002 1 次提交
-
-
由 Tom Lane 提交于
node now does its own grouping of the input rows, and has no need for a preceding GROUP node in the plan pipeline. This allows elimination of the misnamed tuplePerGroup option for GROUP, and actually saves more code in nodeGroup.c than it costs in nodeAgg.c, as well as being presumably faster. Restructure the API of query_planner so that we do not commit to using a sorted or unsorted plan in query_planner; instead grouping_planner makes the decision. (Right now it isn't any smarter than query_planner was, but that will change as soon as it has the option to select a hash- based aggregation step.) Despite all the hackery, no initdb needed since only in-memory node types changed.
-
- 02 11月, 2002 2 次提交
- 15 10月, 2002 2 次提交
-
-
由 Tom Lane 提交于
command status at the interactive level. SPI_processed, etc are set in the same way as the returned command status would have been set if the same querystring were issued interactively. Per gripe from Michael Paesold 25-Sep-02.
-
由 Tom Lane 提交于
query that uses it. This ensures that triggers will be applied consistently throughout a query even if someone commits changes to the relation's pg_class.reltriggers field meanwhile. Per crash report from Laurette Cisneros. While at it, simplify memory management in relcache.c, which no longer needs the old hack to try to keep trigger info in the same place over a relcache entry rebuild. (Should try to fix rd_att and rewrite-rule access similarly, someday.) And make RelationBuildTriggers simpler and more robust by making it build the trigdesc in working memory and then CopyTriggerDesc() into cache memory.
-
- 05 10月, 2002 1 次提交
-
-
由 Tom Lane 提交于
just the significant fields of FunctionCallInfoData, rather than MemSet'ing the whole struct to zero. Unused positions in the arg[] array will thereby contain garbage rather than zeroes. This buys back some of the performance hit from increasing FUNC_MAX_ARGS. Also tweak tuplesort.c code for more speed by marking some routines 'inline'. All together these changes speed up simple sorts, like count(distinct int4column), by about 25% on a P4 running RH Linux 7.2.
-
- 29 9月, 2002 1 次提交
-
-
由 Tom Lane 提交于
remove the special case in ALTER DROP COLUMN to prohibit dropping a table's last column.
-
- 24 9月, 2002 1 次提交
-
-
由 Tom Lane 提交于
executor should not return the tuple as successfully marked, because in fact it's been deleted. Not clear that this case has ever been seen in practice (I think you'd have to write a SELECT FOR UPDATE that calls a function that deletes some row the SELECT will visit later...) but we should be consistent. Also add comments to several other places that got it right but didn't explain what they were doing.
-
- 19 9月, 2002 1 次提交
-
-
由 Tom Lane 提交于
to be flexible about assignment casts without introducing ambiguity in operator/function resolution. Introduce a well-defined promotion hierarchy for numeric datatypes (int2->int4->int8->numeric->float4->float8). Change make_const to initially label numeric literals as int4, int8, or numeric (never float8 anymore). Explicitly mark Func and RelabelType nodes to indicate whether they came from a function call, explicit cast, or implicit cast; use this to do reverse-listing more accurately and without so many heuristics. Explicit casts to char, varchar, bit, varbit will truncate or pad without raising an error (the pre-7.2 behavior), while assigning to a column without any explicit cast will still raise an error for wrong-length data like 7.3. This more nearly follows the SQL spec than 7.2 behavior (we should be reporting a 'completion condition' in the explicit-cast cases, but we have no mechanism for that, so just do silent truncation). Fix some problems with enforcement of typmod for array elements; it didn't work at all in 'UPDATE ... SET array[n] = foo', for example. Provide a generalized array_length_coerce() function to replace the specialized per-array-type functions that used to be needed (and were missing for NUMERIC as well as all the datetime types). Add missing conversions int8<->float4, text<->numeric, oid<->int8. initdb forced.
-
- 05 9月, 2002 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 02 9月, 2002 2 次提交
-
-
由 Bruce Momjian 提交于
because c.h has sys/types.h.
-
由 Tom Lane 提交于
(overlaying low byte of page size) and add HEAP_HASOID bit to t_infomask, per earlier discussion. Simplify scheme for overlaying fields in tuple header (no need for cmax to live in more than one place). Don't try to clear infomask status bits in tqual.c --- not safe to do it there. Don't try to force output table of a SELECT INTO to have OIDs, either. Get rid of unnecessarily complex three-state scheme for TupleDesc.tdhasoids, which has already caused one recent failure. Improve documentation.
-
- 01 9月, 2002 3 次提交
-
-
由 Tom Lane 提交于
type for runtime constraint checks, instead of misusing the parse-time Constraint node for the purpose. Fix some damage introduced into type coercion logic; in particular ensure that a coerced expression tree will read out the correct result type when inspected (patch had broken some RelabelType cases). Enforce domain NOT NULL constraints against columns that are omitted from an INSERT.
-
由 Tom Lane 提交于
-
由 Tom Lane 提交于
you try to use the tupdesc to build a tuple. Joe Conway
-
- 31 8月, 2002 1 次提交
-
-
由 Tom Lane 提交于
functions, per suggestion from John Gray and Joe Conway. Also, fix plpgsql RETURN NEXT to verify that returned values match the expected tupdesc.
-
- 30 8月, 2002 2 次提交
-
-
由 Tom Lane 提交于
that the functionality is available to anyone via ReturnSetInfo, rather than hard-wiring it to PL/pgSQL.
-
由 Tom Lane 提交于
to the table function, thus preventing memory leakage accumulation across calls. This means that SRFs need to be careful to distinguish permanent and local storage; adjust code and documentation accordingly. Patch by Joe Conway, very minor tweaks by Tom Lane.
-
- 29 8月, 2002 2 次提交
-
-
由 Tom Lane 提交于
types, SRFs. Not happy with memory management yet, but I'll commit these other changes.
-
由 Bruce Momjian 提交于
should be pretty safe in practice, but it's probably better to be safe than sorry. I was actually looking for cases where NAMEDATALEN is assumed to be 32, but only found one. That's fixed too, as well as a few bits of code cleanup. Neil Conway
-