- 02 Feb, 2007 1 commit
-
-
Tom Lane authored
made query plan. Use of ALTER COLUMN TYPE creates a hazard for cached query plans: they could contain Vars that claim a column has a different type than it now has. Fix this by checking during plan startup that Vars at relation scan level match the current relation tuple descriptor. Since at that point we already have at least AccessShareLock, we can be sure the column type will not change underneath us later in the query. However, since a backend's locks do not conflict against itself, there is still a hole for an attacker to exploit: he could try to execute ALTER COLUMN TYPE while a query is in progress in the current backend. Seal that hole by rejecting ALTER TABLE whenever the target relation is already open in the current backend. This is a significant security hole: not only can one trivially crash the backend, but with appropriate misuse of pass-by-reference datatypes it is possible to read out arbitrary locations in the server process's memory, which could allow retrieving database content the user should not be able to see. Our thanks to Jeff Trout for the initial report. Security: CVE-2007-0556
-
- 10 Jan, 2007 1 commit
-
-
Tom Lane authored
which comparison operators to use for plan nodes involving tuple comparison (Agg, Group, Unique, SetOp). Formerly the executor looked up the default equality operator for the datatype, which was really pretty shaky, since it's possible that the data being fed to the node is sorted according to some nondefault operator class that could have an incompatible idea of equality. The planner knows what it has sorted by and therefore can provide the right equality operator to use. Also, this change moves a couple of catalog lookups out of the executor and into the planner, which should help startup time for pre-planned queries by some small amount. Modify the planner to remove some other cavalier assumptions about always being able to use the default operators. Also add "nulls first/last" info to the Plan node for a mergejoin --- neither the executor nor the planner can cope yet, but at least the API is in place.
-
- 09 Jan, 2007 1 commit
-
-
Tom Lane authored
per-column options for btree indexes. The planner's support for this is still pretty rudimentary; it does not yet know how to plan mergejoins with nondefault ordering options. The documentation is pretty rudimentary, too. I'll work on improving that stuff later. Note incompatible change from prior behavior: ORDER BY ... USING will now be rejected if the operator is not a less-than or greater-than member of some btree opclass. This prevents less-than-sane behavior if an operator that doesn't actually define a proper sort ordering is selected.
-
- 05 Jan, 2007 1 commit
-
-
Bruce Momjian authored
back-stamped for this.
-
- 04 Oct, 2006 1 commit
-
-
Bruce Momjian authored
-
- 27 Jul, 2006 1 commit
-
-
Tom Lane authored
the opportunity to treat COUNT(*) as a zero-argument aggregate instead of the old hack that equated it to COUNT(1); this is materially cleaner (no more weird ANYOID cases) and ought to be at least a tiny bit faster. Original patch by Sergey Koposov; review, documentation, simple regression tests, pg_dump and psql support by moi.
-
- 14 Jul, 2006 1 commit
-
-
Bruce Momjian authored
-
- 13 Jul, 2006 1 commit
-
-
Bruce Momjian authored
Strip unused include files out unused include files, and add needed includes to C files. The next step is to remove unused include files in C files.
-
- 28 Jun, 2006 2 commits
-
-
Tom Lane authored
tuple hash table entries. This addresses the problem previously noted that use of a 'physical tlist' in the input scan node could bloat the hash table entries far beyond what the planner expects. It's a better answer than my previous thought of undoing the physical tlist optimization, because we can also remove columns that are needed to compute the aggregate functions but aren't part of the grouping column set.
-
Tom Lane authored
-
- 21 Jun, 2006 1 commit
-
-
Tom Lane authored
aggregates. We just disallowed that, and AFAICS there should be no other cases where direct (non-aggregated) references to input columns are allowed in a query with aggregation and no GROUP BY.
-
- 04 Apr, 2006 1 commit
-
-
Tom Lane authored
functions are not strict, they will be called (passing a NULL first parameter) during any attempt to input a NULL value of their datatype. Currently, all our input functions are strict and so this commit does not change any behavior. However, this will make it possible to build domain input functions that centralize checking of domain constraints, thereby closing numerous holes in our domain support, as per previous discussion. While at it, I took the opportunity to introduce convenience functions InputFunctionCall, OutputFunctionCall, etc to use in code that calls I/O functions. This eliminates a lot of grotty-looking casts, but the main motivation is to make it easier to grep for these places if we ever need to touch them again.
-
- 05 Mar, 2006 1 commit
-
-
Bruce Momjian authored
-
- 28 Feb, 2006 1 commit
-
-
Tom Lane authored
bits indicating which optional capabilities can actually be exercised at runtime. This will allow Sort and Material nodes, and perhaps later other nodes, to avoid unnecessary overhead in common cases. This commit just adds the infrastructure and arranges to pass the correct flag values down to plan nodes; none of the actual optimizations are here yet. I'm committing this separately in case anyone wants to measure the added overhead. (It should be negligible.) Simon Riggs and Tom Lane
-
- 22 Nov, 2005 1 commit
-
-
Bruce Momjian authored
comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
-
- 15 Oct, 2005 1 commit
-
-
Bruce Momjian authored
-
- 28 Jun, 2005 1 commit
-
-
Tom Lane authored
and pg_auth_members. There are still many loose ends to finish in this patch (no documentation, no regression tests, no pg_dump support for instance). But I'm going to commit it now anyway so that Alvaro can make some progress on shared dependencies. The catalog changes should be pretty much done.
-
- 06 May, 2005 1 commit
-
-
Tom Lane authored
which is neither needed by nor related to that header. Remove the bogus inclusion and instead include the header in those C files that actually need it. Also fix unnecessary inclusions and bad inclusion order in tsearch2 files.
-
- 29 Mar, 2005 1 commit
-
-
Tom Lane authored
change saves a great deal of space in pg_proc and its primary index, and it eliminates the former requirement that INDEX_MAX_KEYS and FUNC_MAX_ARGS have the same value. INDEX_MAX_KEYS is still embedded in the on-disk representation (because it affects index tuple header size), but FUNC_MAX_ARGS is not. I believe it would now be possible to increase FUNC_MAX_ARGS at little cost, but haven't experimented yet. There are still a lot of vestigial references to FUNC_MAX_ARGS, which I will clean up in a separate pass. However, getting rid of it altogether would require changing the FunctionCallInfoData struct, and I'm not sure I want to buy into that.
-
- 22 Mar, 2005 1 commit
-
-
Tom Lane authored
critical places in execQual. By Atsushi Ogawa; some minor cleanup by moi.
-
- 16 Mar, 2005 1 commit
-
-
Tom Lane authored
of tuples when passing data up through multiple plan nodes. A slot can now hold either a normal "physical" HeapTuple, or a "virtual" tuple consisting of Datum/isnull arrays. Upper plan levels can usually just copy the Datum arrays, avoiding heap_formtuple() and possible subsequent nocachegetattr() calls to extract the data again. This work extends Atsushi Ogawa's earlier patch, which provided the key idea of adding Datum arrays to TupleTableSlots. (I believe however that something like this was foreseen way back in Berkeley days --- see the old comment on ExecProject.) A test case involving many levels of join of fairly wide tables (about 80 columns altogether) showed about 3x overall speedup, though simple queries will probably not be helped very much. I have also duplicated some code in heaptuple.c in order to provide versions of heap_formtuple and friends that use "bool" arrays to indicate null attributes, instead of the old convention of "char" arrays containing either 'n' or ' '. This provides a better match to the convention used by ExecEvalExpr. While I have not made a concerted effort to get rid of uses of the old routines, I think they should be deprecated and eventually removed.
-
- 12 Mar, 2005 1 commit
-
-
Tom Lane authored
can tell whether it is being used as an aggregate or not. This allows such a function to avoid re-pallocing a pass-by-reference transition value; normally it would be unsafe for a function to scribble on an input, but in the aggregate case it's safe to reuse the old transition value. Make int8inc() do this. This gets a useful improvement in the speed of COUNT(*), at least on narrow tables (it seems to be swamped by I/O when the table rows are wide). Per a discussion in early December with Neil Conway. I also fixed int_aggregate.c to check this, thereby turning it into something approaching a supportable technique instead of being a crude hack.
-
- 28 Jan, 2005 1 commit
-
-
Tom Lane authored
look at the actual aggregate transition datatypes and the actual overhead needed by nodeAgg.c, instead of using pessimistic round numbers. Per a discussion with Michael Tiemann.
-
- 27 Jan, 2005 1 commit
-
-
Tom Lane authored
functions of the aggregate, at both aggregate creation and execution times.
-
- 31 Dec, 2004 1 commit
-
-
PostgreSQL Daemon authored
Tag appropriate files for rc3 Also performed an initial run through of upgrading our Copyright date to extend to 2005 ... first run here was very simple ... change everything where: grep 1996-2004 && the word 'Copyright' ... scanned through the generated list with 'less' first, and after, to make sure that I only picked up the right entries ...
-
- 29 Aug, 2004 2 commits
-
-
Bruce Momjian authored
-
Bruce Momjian authored
-
- 10 Jul, 2004 1 commit
-
-
Tom Lane authored
This is required by SQL spec to avoid failures in cases like SELECT sum(win)/sum(lose) FROM ... GROUP BY ... HAVING sum(lose) > 0; AFAICT we have gotten this wrong since day one. Kudos to Holger Jakobs for being the first to notice.
-
- 06 Jun, 2004 1 commit
-
-
Tom Lane authored
of a composite type to get that type's OID as their second parameter, in place of typelem which is useless. The actual changes are mostly centralized in getTypeInputInfo and siblings, but I had to fix a few places that were fetching pg_type.typelem for themselves instead of using the lsyscache.c routines. Also, I renamed all the related variables from 'typelem' to 'typioparam' to discourage people from assuming that they necessarily contain array element types.
-
- 30 May, 2004 1 commit
-
-
Neil Conway authored
list compatibility API by default. While doing this, I decided to keep the llast() macro around and introduce llast_int() and llast_oid() variants.
-
- 26 May, 2004 1 commit
-
-
Neil Conway authored
In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
-
- 13 Mar, 2004 1 commit
-
-
Tom Lane authored
7.4 rewrite for hashed aggregate support. If the transition data type is pass-by-reference, the transValue must be pfreed when starting a new group boundary, else we have a one-value-per-group leakage. Thanks to Rae Steining for providing a reproducible test case.
-
- 03 Feb, 2004 1 commit
-
-
Tom Lane authored
Make btree index creation and initial validation of foreign-key constraints use maintenance_work_mem rather than work_mem as their memory limit. Add some code to guc.c to allow these variables to be referenced by their old names in SHOW and SET commands, for backwards compatibility.
-
- 29 Nov, 2003 1 commit
-
-
PostgreSQL Daemon authored
$Header: -> $PostgreSQL Changes ...
-
- 19 Aug, 2003 1 commit
-
-
Tom Lane authored
as well as the hash function (formerly the comparison function was hardwired as memcmp()). This makes it possible to eliminate the special-purpose hashtable management code in execGrouping.c in favor of using dynahash to manage tuple hashtables; which is a win because dynahash knows how to expand a hashtable when the original size estimate was too small, whereas the special-purpose code was too stupid to do that. (See recent gripe from Stephan Szabo about poor performance when hash table size estimate is way off.) Free side benefit: when using string_hash, the default comparison function is now strncmp() instead of memcmp(). This should eliminate some part of the overhead associated with larger NAMEDATALEN values.
-
- 08 Aug, 2003 1 commit
-
-
Bruce Momjian authored
-
- 04 Aug, 2003 2 commits
-
-
Bruce Momjian authored
-
Bruce Momjian authored
-
- 01 Aug, 2003 1 commit
-
-
Tom Lane authored
-
- 21 Jul, 2003 1 commit
-
-
Tom Lane authored
-