- 04 8月, 2003 2 次提交
-
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
- 01 8月, 2003 1 次提交
-
-
由 Tom Lane 提交于
-
- 28 7月, 2003 1 次提交
-
-
由 Tom Lane 提交于
-
- 22 7月, 2003 1 次提交
-
-
由 Tom Lane 提交于
-
- 09 5月, 2003 1 次提交
-
-
由 Tom Lane 提交于
handle multiple 'formats' for data I/O. Restructure CommandDest and DestReceiver stuff one more time (it's finally starting to look a bit clean though). Code now matches latest 3.0 protocol document as far as message formats go --- but there is no support for binary I/O yet.
-
- 07 5月, 2003 1 次提交
-
-
由 Tom Lane 提交于
DestReceiver pointers instead of just CommandDest values. The DestReceiver is made at the point where the destination is selected, rather than deep inside the executor. This cleans up the original kluge implementation of tstoreReceiver.c, and makes it easy to support retrieving results from utility statements inside portals. Thus, you can now do fun things like Bind and Execute a FETCH or EXPLAIN command, and it'll all work as expected (e.g., you can Describe the portal, or use Execute's count parameter to suspend the output partway through). Implementation involves stuffing the utility command's output into a Tuplestore, which would be kind of annoying for huge output sets, but should be quite acceptable for typical uses of utility commands.
-
- 06 5月, 2003 2 次提交
-
-
由 Tom Lane 提交于
the column by table OID and column number, if it's a simple column reference. Along the way, get rid of reskey/reskeyop fields in Resdoms. Turns out that representation was not convenient for either the planner or the executor; we can make the planner deliver exactly what the executor wants with no more effort. initdb forced due to change in stored rule representation.
-
由 Tom Lane 提交于
which does the same thing. Perhaps at one time there was a reason to allow plan nodes to store their result types in different places, but AFAICT that's been unnecessary for a good while.
-
- 28 3月, 2003 1 次提交
-
-
由 Bruce Momjian 提交于
(materialization into a tuple store) discussed on pgsql-hackers earlier. I've updated the documentation and the regression tests. Notes on the implementation: - I needed to change the tuple store API slightly -- it assumes that it won't be used to hold data across transaction boundaries, so the temp files that it uses for on-disk storage are automatically reclaimed at end-of-transaction. I added a flag to tuplestore_begin_heap() to control this behavior. Is changing the tuple store API in this fashion OK? - in order to store executor results in a tuple store, I added a new CommandDest. This works well for the most part, with one exception: the current DestFunction API doesn't provide enough information to allow the Executor to store results into an arbitrary tuple store (where the particular tuple store to use is chosen by the call site of ExecutorRun). To workaround this, I've temporarily hacked up a solution that works, but is not ideal: since the receiveTuple DestFunction is passed the portal name, we can use that to lookup the Portal data structure for the cursor and then use that to get at the tuple store the Portal is using. This unnecessarily ties the Portal code with the tupleReceiver code, but it works... The proper fix for this is probably to change the DestFunction API -- Tom suggested passing the full QueryDesc to the receiveTuple function. In that case, callers of ExecutorRun could "subclass" QueryDesc to add any additional fields that their particular CommandDest needed to get access to. This approach would work, but I'd like to think about it for a little bit longer before deciding which route to go. In the mean time, the code works fine, so I don't think a fix is urgent. - (semi-related) I added a NO SCROLL keyword to DECLARE CURSOR, and adjusted the behavior of SCROLL in accordance with the discussion on -hackers. - (unrelated) Cleaned up some SGML markup in sql.sgml, copy.sgml Neil Conway
-
- 27 3月, 2003 1 次提交
-
-
由 Tom Lane 提交于
qual checking, not GetCurrentCommandId. Per test case from Steve Wolfe.
-
- 20 3月, 2003 1 次提交
-
-
由 Bruce Momjian 提交于
Neil Conway
-
- 12 3月, 2003 1 次提交
-
-
由 Tom Lane 提交于
for FETCH and MOVE.
-
- 10 3月, 2003 1 次提交
-
-
由 Tom Lane 提交于
utility statement (DeclareCursorStmt) with a SELECT query dangling from it, rather than a SELECT query with a few unusual fields in it. Add code to determine whether a planned query can safely be run backwards. If DECLARE CURSOR specifies SCROLL, ensure that the plan can be run backwards by adding a Materialize plan node if it can't. Without SCROLL, you get an error if you try to fetch backwards from a cursor that can't handle it. (There is still some discussion about what the exact behavior should be, but this is necessary infrastructure in any case.) Along the way, make EXPLAIN DECLARE CURSOR work.
-
- 03 2月, 2003 1 次提交
-
-
由 Tom Lane 提交于
nodes where it's not really necessary. In many cases where the scan node is not the topmost plan node (eg, joins, aggregation), it's possible to just return the table tuple directly instead of generating an intermediate projection tuple. In preliminary testing, this reduced the CPU time needed for 'SELECT COUNT(*) FROM foo' by about 10%.
-
- 23 1月, 2003 1 次提交
-
-
由 Tom Lane 提交于
for backwards compatibility with pre-7.3 behavior. Per discussion on pgsql-general and pgsql-hackers.
-
- 13 1月, 2003 1 次提交
-
-
由 Peter Eisentraut 提交于
-
- 11 1月, 2003 1 次提交
-
-
由 Peter Eisentraut 提交于
-
- 09 1月, 2003 1 次提交
-
-
由 Tom Lane 提交于
-
- 18 12月, 2002 1 次提交
-
-
由 Tom Lane 提交于
It doesn't leak memory anymore ...
-
- 16 12月, 2002 2 次提交
-
-
由 Tom Lane 提交于
given any malloc block until something is first allocated in it; but thereafter, MemoryContextReset won't release that first malloc block. This preserves the quick-reset property of the original policy, without forcing 8K to be allocated to every context whether any of it is ever used or not. Also, remove some more no-longer-needed explicit freeing during ExecEndPlan.
-
由 Tom Lane 提交于
a per-query memory context created by CreateExecutorState --- and destroyed by FreeExecutorState. This provides a final solution to the longstanding problem of memory leaked by various ExecEndNode calls.
-
- 14 12月, 2002 1 次提交
-
-
由 Tom Lane 提交于
execution state trees, and ExecEvalExpr takes an expression state tree not an expression plan tree. The plan tree is now read-only as far as the executor is concerned. Next step is to begin actually exploiting this property.
-
- 12 12月, 2002 1 次提交
-
-
由 Tom Lane 提交于
so that all executable expression nodes inherit from a common supertype Expr. This is somewhat of an exercise in code purity rather than any real functional advance, but getting rid of the extra Oper or Func node formerly used in each operator or function call should provide at least a little space and speed improvement. initdb forced by changes in stored-rules representation.
-
- 05 12月, 2002 2 次提交
-
-
由 Tom Lane 提交于
to plan nodes, not vice-versa. All executor state nodes now inherit from struct PlanState. Copying of plan trees has been simplified by not storing a list of SubPlans in Plan nodes (eliminating duplicate links). The executor still needs such a list, but it can build it during ExecutorStart since it has to scan the plan tree anyway. No initdb forced since no stored-on-disk structures changed, but you will need a full recompile because of node-numbering changes.
-
由 Bruce Momjian 提交于
-
- 30 11月, 2002 1 次提交
-
-
由 Tom Lane 提交于
-
- 23 11月, 2002 1 次提交
-
-
由 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
-
- 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
-
- 15 10月, 2002 1 次提交
-
-
由 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.
-
- 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.
-
- 05 9月, 2002 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 02 9月, 2002 1 次提交
-
-
由 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.
-
- 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
-