- 06 8月, 2008 1 次提交
-
-
由 Tom Lane 提交于
sure that DISTINCT ON does what it's supposed to, ie, sort by the full ORDER BY list before unique-ifying. The error seems masked in simple cases by the fact that query_planner won't return query pathkeys that only partially match the requested sort order, but I wouldn't want to bet that it couldn't be exposed in some way or other.
-
- 05 8月, 2008 6 次提交
-
-
由 Tom Lane 提交于
-
由 Tom Lane 提交于
PageHeaderIsValid when we zero the buffer instead of reading the page in. The actual performance improvement is probably marginal since this function isn't very heavily used, but a cycle saved is a cycle earned. Zdenek Kotala
-
由 Magnus Hagander 提交于
This allows the use of a ramdrive (either through mount or symlink) for the temporary file that's written every half second, which should reduce I/O. On server shutdown/startup, the file is written to the old location in the global directory, to preserve data across restarts. Bump catversion since the $PGDATA directory layout changed.
-
由 Tom Lane 提交于
some failures to expose messages for translation.
-
由 Tom Lane 提交于
as methods for implementing the DISTINCT step. This eliminates the former performance gap between DISTINCT and GROUP BY, and also makes it possible to do SELECT DISTINCT on datatypes that only support hashing not sorting. SELECT DISTINCT ON is still always implemented by sorting; it would take executor changes to support hashing that, and it's not clear it's worth the trouble. This is a release-note-worthy incompatibility from previous PG versions, since SELECT DISTINCT can no longer be counted on to deliver sorted output without explicitly saying ORDER BY. (Anyone who can't cope with that can consider turning off enable_hashagg.) Several regression test queries needed to have ORDER BY added to preserve stable output order. I fixed the ones that manifested here, but there might be some other cases that show up on other platforms.
-
由 Tom Lane 提交于
or target database is being accessed by other users, it tells you whether the "other users" are live sessions or uncommitted prepared transactions. (Indeed, it tells you exactly how many of each, but that's mostly just because it was easy to do so.) This should help forestall the gotcha of not realizing that a prepared transaction is what's blocking the command. Per discussion.
-
- 04 8月, 2008 1 次提交
-
-
由 Tom Lane 提交于
sorting. The infrastructure for this was all in place already; it's only necessary to fix the planner to not assume that sorting is always an available option.
-
- 03 8月, 2008 3 次提交
-
-
由 Tom Lane 提交于
a size that is one of the supported values, not just anything <= sizeof(Datum). Cross-check the alignment specification against size as well.
-
由 Tom Lane 提交于
read when the --temp-config argument is bad. Noted while wondering why buildfarm member dungbeetle is failing ... this isn't why, but it is why the error report isn't very helpful ...
-
由 Tom Lane 提交于
as per my recent proposal: 1. Fold SortClause and GroupClause into a single node type SortGroupClause. We were already relying on them to be struct-equivalent, so using two node tags wasn't accomplishing much except to get in the way of comparing items with equal(). 2. Add an "eqop" field to SortGroupClause to carry the associated equality operator. This is cheap for the parser to get at the same time it's looking up the sort operator, and storing it eliminates the need for repeated not-so-cheap lookups during planning. In future this will also let us represent GROUP/DISTINCT operations on datatypes that have hash opclasses but no btree opclasses (ie, they have equality but no natural sort order). The previous representation simply didn't work for that, since its only indicator of comparison semantics was a sort operator. 3. Add a hasDistinctOn boolean to struct Query to explicitly record whether the distinctClause came from DISTINCT or DISTINCT ON. This allows removing some complicated and not 100% bulletproof code that attempted to figure that out from the distinctClause alone. This patch doesn't in itself create any new capability, but it's necessary infrastructure for future attempts to use hash-based grouping for DISTINCT and UNION/INTERSECT/EXCEPT.
-
- 01 8月, 2008 7 次提交
-
-
由 Alvaro Herrera 提交于
numbered program. Per persistent buildfarm failures. Tom Lane
-
由 Alvaro Herrera 提交于
Robert Lor
-
由 Magnus Hagander 提交于
method is grouped together in a reasonably similar way, keeping the "global shared functions" together in their own section as well. Makes it a lot easier to find your way around the code.
-
由 Magnus Hagander 提交于
routines, leaving hba.c to deal only with processing the HBA specific files.
-
由 Tom Lane 提交于
to represent DISTINCT or DISTINCT ON. This gets rid of a longstanding annoyance that a view or rule using SELECT DISTINCT will be dumped out with an overspecified ORDER BY list, and is one small step along the way to decoupling DISTINCT and ORDER BY enough so that hash-based implementation of DISTINCT will be possible. In passing, improve transformDistinctClause so that it doesn't reject duplicate DISTINCT ON items, as was reported by Steve Midgley a couple weeks ago.
-
由 Bruce Momjian 提交于
* Consider decreasing the I/O caused by updating tuple hint bits > http://archives.postgresql.org/pgsql-patches/2008-07/msg00199.php
-
由 Tom Lane 提交于
or domains). This was already effectively required because you had to own the I/O functions, and the I/O functions pretty much have to be written in C since we don't let PL functions take or return cstring. But given the possible security consequences of a malicious type definition, it seems prudent to enforce superuser requirement directly. Per recent discussion.
-
- 31 7月, 2008 4 次提交
-
-
由 Tom Lane 提交于
of the STRING type category, thereby opening up the mechanism for user-defined types. This is mainly for the benefit of citext, though; there aren't likely to be a lot of types that are all general-purpose character strings. Per discussion with David Wheeler.
-
由 Tom Lane 提交于
only type categories in which the previous coding made *every* type preferred; so there is no change in effective behavior, because the function resolution rules only do something different when faced with a choice between preferred and non-preferred types in the same category. It just seems safer and less surprising to have CREATE TYPE default to non-preferred status ...
-
由 Tom Lane 提交于
by putting it into the standard string category, we cause casts from citext to text to be recognized as "preferred" casts. This eliminates the need for creation of alias functions and operators that only serve to prevent ambiguous-function errors; get rid of the ones that were in the original commit.
-
由 Tom Lane 提交于
with system catalog lookups, as was foreseen to be necessary almost since their creation. Instead put the information into two new pg_type columns, typcategory and typispreferred. Add support for setting these when creating a user-defined base type. The category column is just a "char" (i.e. a poor man's enum), allowing a crude form of user extensibility of the category list: just use an otherwise-unused character. This seems sufficient for foreseen uses, but we could upgrade to having an actual category catalog someday, if there proves to be a huge demand for custom type categories. In this patch I have attempted to hew exactly to the behavior of the previous hardwired logic, except for introducing new type categories for arrays, composites, and enums. In particular the default preferred state for user-defined types remains TRUE. That seems worth revisiting, but it should be done as a separate patch from introducing the infrastructure. Likewise, any adjustment of the standard set of categories should be done separately.
-
- 30 7月, 2008 1 次提交
-
-
由 Tom Lane 提交于
David E. Wheeler
-
- 29 7月, 2008 2 次提交
-
-
由 Magnus Hagander 提交于
SGML source but in the actual web/pdf viewer...
-
由 Magnus Hagander 提交于
for building on MSVC, and that the free distribution is enough (no need for the enterprise version). Per gripe from Martin Zaun.
-
- 27 7月, 2008 1 次提交
-
-
由 Tom Lane 提交于
filter to be used when INSERT or SELECT INTO has a plan that returns raw disk tuples. The virtual-tuple-slot optimizations that were put in place awhile ago mean that ExecInsert has to do ExecMaterializeSlot, and that already copies the tuple if it's raw (and does so more efficiently than a junk filter, too). So get rid of that logic. This in turn means that we can throw away ExecMayReturnRawTuples, which wasn't used for any other purpose, and was always a kluge anyway. In passing, move a couple of SELECT-INTO-specific fields out of EState and into the private state of the SELECT INTO DestReceiver, as was foreseen in an old comment there. Also make intorel_receive use ExecMaterializeSlot not ExecCopySlotTuple, for consistency with ExecInsert and to possibly save a tuple copy step in some cases.
-
- 25 7月, 2008 2 次提交
- 24 7月, 2008 3 次提交
-
-
由 Alvaro Herrera 提交于
Simon Riggs
-
由 Tom Lane 提交于
default_reloptions(). The previous coding was really a bug because pg_atoi() will always throw elog on bad input data, whereas default_reloptions is not supposed to complain about bad input unless its validate parameter is true. Right now you could only expose the problem by hand-modifying pg_class.reloptions into an invalid state, so it doesn't seem worth back-patching; but we should get it right in HEAD because there might be other situations in future. Noted while studying GIN fast-update patch.
-
由 Peter Eisentraut 提交于
This is required because the value is substituted into the pltcl_*mod scripts.
-
- 23 7月, 2008 1 次提交
-
-
由 Tom Lane 提交于
(Extracted from fast-insert patch, since it ought to be back-patched)
-
- 21 7月, 2008 4 次提交
-
-
由 Alvaro Herrera 提交于
protection. Simon Riggs
-
由 Tom Lane 提交于
has to deal with.
-
由 Tom Lane 提交于
and bogus documentation (dimension arrays are int[] not anyarray). Also the errhint() messages seem to be really errdetail(), since there is nothing heuristic about them. Some other trivial cosmetic improvements.
-
由 Tom Lane 提交于
to acquire shared table locks within a specified amount of time. David Gould
-
- 20 7月, 2008 1 次提交
-
-
由 Bruce Momjian 提交于
In psql, run .psqlrc _after_ printing warnings and banner.
-
- 19 7月, 2008 3 次提交
-
-
由 Tom Lane 提交于
the postgres.bki file during build, because we want that file to be entirely platform- and configuration-independent; else it can't safely be put into /usr/share on multiarch machines. We can do the substitution during initdb, instead. FLOAT4PASSBYVAL and FLOAT8PASSBYVAL are new breakage as of 8.4, while the NAMEDATALEN hazard has been there all along but I guess no one tripped over it. Noticed while trying to build "universal" OS X binaries.
-
由 Tom Lane 提交于
a portal are never NULL, but reliably provide the source text of the query. It turns out that there was only one place that was really taking a short-cut, which was the 'EXECUTE' utility statement. That doesn't seem like a sufficiently critical performance hotspot to justify not offering a guarantee of validity of the portal source text. Fix it to copy the source text over from the cached plan. Add Asserts in the places that set up cached plans and portals to reject null source strings, and simplify a bunch of places that formerly needed to guard against nulls. There may be a few places that cons up statements for execution without having any source text at all; I found one such in ConvertTriggerToFK(). It seems sufficient to inject a phony source string in such a case, for instance ProcessUtility((Node *) atstmt, "(generated ALTER TABLE ADD FOREIGN KEY command)", NULL, false, None_Receiver, NULL); We should take a second look at the usage of debug_query_string, particularly the recently added current_query() SQL function. ITAGAKI Takahiro and Tom Lane
-
由 Tom Lane 提交于
ITAGAKI Takahiro
-