- 31 12月, 2006 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 30 12月, 2006 2 次提交
- 29 12月, 2006 7 次提交
-
-
由 Peter Eisentraut 提交于
-
由 Tom Lane 提交于
or contradictory keys even in cross-data-type scenarios. This is another benefit of the opfamily rewrite: we can find the needed comparison operators now.
-
由 Bruce Momjian 提交于
< * Add a GUC to control whether BEGIN inside a transcation should abort < the transaction.
-
由 Tom Lane 提交于
for use with constraint exclusion. We can prove those cases now...
-
由 Tom Lane 提交于
predicate operators. The hard stuff turns out to be already done in the previous commit, we need merely open the floodgates...
-
由 Bruce Momjian 提交于
< * Move some /contrib modules out to their own project sites < < Particularly, move GPL-licensed /contrib/userlock and < /contrib/dbmirror/clean_pending.pl. <
-
- 28 12月, 2006 11 次提交
-
-
由 Peter Eisentraut 提交于
-
由 Peter Eisentraut 提交于
-
由 Tom Lane 提交于
the 8.1 SQL function definition for it. Per report from Rajesh Kumar Mallah, such a DBA error doesn't seem at all improbable, and the cost of checking for it is not very high compared to the cost of running this function. (It would have been better to change the C name of the function so it wouldn't be called by the old SQL definition, but it's too late for that now in the 8.2 branch.)
-
由 Tom Lane 提交于
do this for ordinary SQL commands, so it seems consistent to do it for backslash commands too. Per gripe from Rajesh Kumar Mallah.
-
由 Tom Lane 提交于
-
由 Tom Lane 提交于
Per Thorkil Olesen.
-
由 Bruce Momjian 提交于
multi-line comments to the next line.
-
由 Tom Lane 提交于
of increasing size, instead of one at a time. This reduces the memory management overhead when num_temp_buffers is large: in the previous coding we would actually waste 50% of the space used for temp buffers, because aset.c would round the individual requests up to 16K. Problem noted while studying a performance issue reported by Steven Flatt. Back-patch as far as 8.1 --- older versions used few enough local buffers that the issue isn't significant for them.
-
由 Tom Lane 提交于
has a small maxBlockSize: the maximum request size that we will treat as a "chunk" needs to be limited to fit in maxBlockSize. Otherwise we will round up the request size to the next power of 2, wasting space, which is a bit pointless if we aren't going to make the blocks big enough to fit additional stuff in them. The example motivating this is local buffer management, which makes repeated allocations of 8K (one BLCKSZ buffer) in TopMemoryContext, which has maxBlockSize = 8K because for the most part allocations there are small. This leads to each local buffer actually eating 16K of space, which adds up when there are thousands of them. I intend to change localbuf.c to aggregate its requests, which will prevent this particular misbehavior, but it seems likely that similar scenarios could arise elsewhere, so fixing the core problem seems wise as well.
-
由 Tom Lane 提交于
PQdsplen()) normally, instead of replacing them by \uXXXX sequences. Assume that they in fact occupy zero screen space for formatting purposes. Per gripe from Michael Fuhr and ensuing discussion.
-
由 Tom Lane 提交于
remove long-obsolete statement that there isn't a check for infinite recursion in view rules.
-
- 27 12月, 2006 5 次提交
-
-
由 Bruce Momjian 提交于
-
由 Tom Lane 提交于
involving HashAggregate over SubqueryScan (this is the known case, there may well be more). The bug is only latent in releases before 8.2 since they didn't try to access tupletable slots' descriptors during ExecDropTupleTable. The least bogus fix seems to be to make subqueries share the parent query's memory context, so that tupdescs they create will have the same lifespan as those of the parent query. There are comments in the code envisioning going even further by not having a separate child EState at all, but that will require rethinking executor access to range tables, which I don't want to tackle right now. Per bug report from Jean-Pierre Pelletier.
-
由 Tom Lane 提交于
ps_TupFromTlist in plan nodes that make use of it. This was being done correctly in join nodes and Result nodes but not in any relation-scan nodes. Bug would lead to bogus results if a set-returning function appeared in the targetlist of a subquery that could be rescanned after partial execution, for example a subquery within EXISTS(). Bug has been around forever :-( ... surprising it wasn't reported before.
-
由 Tom Lane 提交于
were marked canSetTag. While it's certainly correct to return the result of the last one that is marked canSetTag, it's less clear what to do when none of them are. Since plpgsql will complain if zero is returned, the 8.2.0 behavior isn't good. I've fixed it to restore the prior behavior of returning the physically last query's result code when there are no canSetTag queries.
-
由 Tom Lane 提交于
-
- 26 12月, 2006 2 次提交
-
-
由 Teodor Sigaev 提交于
-
由 Tatsuo Ishii 提交于
pgbench calls random() later, so it should have called srandom(). On most platforms except Windows srandom() is actually identical to srand(), so the bug only bites Windows users. per bug report from Akio Ishida.
-
- 25 12月, 2006 2 次提交
-
-
由 Tom Lane 提交于
operations during recent code refactoring). Per bug #2840 from Ned Crigler.
-
由 Tom Lane 提交于
Use a TRY block instead of (inadequate) ad-hoc coding to ensure that libxml is cleaned up after a failure. Report the intended SQLCODE instead of defaulting to XX000. Avoid risking use of a dangling pointer by keeping the persistent error buffer in TopMemoryContext. Be less trusting that error messages don't contain %. This patch doesn't do anything about changing the way the messages are put together --- this is just about mechanism.
-
- 24 12月, 2006 2 次提交
-
-
由 Tom Lane 提交于
bletcherous and unsafe manipulation of global encoding setting. Clean up libxml reporting mechanism a bit (it still looks like a dangling-pointer crash waiting to happen, though, not to mention being far less than sane from a localization standpoint).
-
由 Tom Lane 提交于
the XmlExpr code in various lists, use a representation that has some hope of reverse-listing correctly (though it's still a de-escaping function shy of correctness), generally try to make it look more like Postgres coding conventions.
-
- 23 12月, 2006 8 次提交
-
-
由 Tom Lane 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
and UPDATE are clearly covered by the term.
-
由 Bruce Momjian 提交于
rather than being disallowed.
-
由 Bruce Momjian 提交于
require at least two characters for uniqueness. This now matches the behavior of other boolean strings we support, per report from Gurjeet Singh.
-
由 Tom Lane 提交于
cases. Operator classes now exist within "operator families". While most families are equivalent to a single class, related classes can be grouped into one family to represent the fact that they are semantically compatible. Cross-type operators are now naturally adjunct parts of a family, without having to wedge them into a particular opclass as we had done originally. This commit restructures the catalogs and cleans up enough of the fallout so that everything still works at least as well as before, but most of the work needed to actually improve the planner's behavior will come later. Also, there are not yet CREATE/DROP/ALTER OPERATOR FAMILY commands; the only way to create a new family right now is to allow CREATE OPERATOR CLASS to make one by default. I owe some more documentation work, too. But that can all be done in smaller pieces once this infrastructure is in place.
-
由 Bruce Momjian 提交于
work effectively with open source communities.
-
由 Bruce Momjian 提交于
added.
-