aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAge
* Make GROUP BY work properly for datatypes that only support hashing and notTom Lane2008-08-03
| | | | | | 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.
* Tighten up the sanity checks in TypeCreate(): pass-by-value types must haveTom Lane2008-08-03
| | | | | a size that is one of the supported values, not just anything <= sizeof(Datum). Cross-check the alignment specification against size as well.
* Fix copy-and-pasteo that's causing pg_regress to lie about which file it can'tTom Lane2008-08-03
| | | | | | 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 ...
* Rearrange the querytree representation of ORDER BY/GROUP BY/DISTINCT itemsTom Lane2008-08-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Cope with Tcl versions that do not create a tclsh symlink to the version-Alvaro Herrera2008-08-01
| | | | | | numbered program. Per persistent buildfarm failures. Tom Lane
* Add a few more DTrace probes to the backend.Alvaro Herrera2008-08-01
| | | | Robert Lor
* Rearrange the code in auth.c so that all functions for a single authenticationMagnus Hagander2008-08-01
| | | | | | 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.
* Move ident authentication code into auth.c along with the other authenciationMagnus Hagander2008-08-01
| | | | routines, leaving hba.c to deal only with processing the HBA specific files.
* Fix parser so that we don't modify the user-written ORDER BY list in orderTom Lane2008-07-31
| | | | | | | | | | 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.
* Add URL to:Bruce Momjian2008-07-31
| | | | | | * Consider decreasing the I/O caused by updating tuple hint bits > http://archives.postgresql.org/pgsql-patches/2008-07/msg00199.php
* Require superuser privilege to create base types (but not composites, enums,Tom Lane2008-07-31
| | | | | | | | 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.
* Allow I/O conversion casts to be applied to or from any type that is a memberTom Lane2008-07-30
| | | | | | | 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.
* Flip the default typispreferred setting from true to false. This affectsTom Lane2008-07-30
| | | | | | | | | 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 ...
* Adjust citext to make use of the new ability to declare its type category:Tom Lane2008-07-30
| | | | | | | | 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.
* Replace the hard-wired type knowledge in TypeCategory() and IsPreferredType()Tom Lane2008-07-30
| | | | | | | | | | | | | | | | | | | | | 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.
* Add a new, improved version of citext as a contrib module.Tom Lane2008-07-29
| | | | David E. Wheeler
* Cleanup reference to config.pl so it makes sense not only inMagnus Hagander2008-07-29
| | | | SGML source but in the actual web/pdf viewer...
* Document which versions of ActivePerl and ActiveTcl are requiredMagnus Hagander2008-07-29
| | | | | | | for building on MSVC, and that the free distribution is enough (no need for the enterprise version). Per gripe from Martin Zaun.
* As noted by Andrew Gierth, there's really no need any more to force a junkTom Lane2008-07-26
| | | | | | | | | | | | | | | | 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.
* Fix parsing of LDAP URLs so it doesn't reject spaces in the "suffix" part.Tom Lane2008-07-24
| | | | Per report from César Miguel Oliveira Alves.
* Remove some redundant tests and improve comments in next_token().Tom Lane2008-07-24
| | | | Cosmetic, but it might make this a bit less confusing to the next reader.
* Ratchet up patch to improve autovacuum wraparound messages.Alvaro Herrera2008-07-23
| | | | Simon Riggs
* Use guc.c's parse_int() instead of pg_atoi() to parse fillfactor inTom Lane2008-07-23
| | | | | | | | | | 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.
* Abort if Tcl support was configured and no tcl shell was found.Peter Eisentraut2008-07-23
| | | | | This is required because the value is substituted into the pltcl_*mod scripts.
* Update link to Oleg and Teodor's GIN page.Tom Lane2008-07-22
| | | | (Extracted from fast-insert patch, since it ought to be back-patched)
* Publish more openly the fact that autovacuum is working for wraparoundAlvaro Herrera2008-07-21
| | | | | | protection. Simon Riggs
* Add comment about the two different query strings that ExecuteQuery()Tom Lane2008-07-21
| | | | has to deal with.
* Code review for array_fill patch: fix inadequate check for array size overflowTom Lane2008-07-21
| | | | | | 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.
* Add a pg_dump option --lock-wait-timeout to allow failing the dump if unableTom Lane2008-07-20
| | | | | | to acquire shared table locks within a specified amount of time. David Gould
* Revert patch so .psqlrc can suppress startup banner:Bruce Momjian2008-07-20
| | | | In psql, run .psqlrc _after_ printing warnings and banner.
* Avoid substituting NAMEDATALEN, FLOAT4PASSBYVAL, and FLOAT8PASSBYVAL intoTom Lane2008-07-19
| | | | | | | | | 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.
* Adjust things so that the query_string of a cached plan and the sourceText ofTom Lane2008-07-18
| | | | | | | | | | | | | | | | | | | | | | | | 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
* Provide a function hook to let plug-ins get control around ExecutorRun.Tom Lane2008-07-18
| | | | ITAGAKI Takahiro
* Properly document archive/restore command examples on Windows.Bruce Momjian2008-07-18
| | | | ITAGAKI Takahiro
* In psql, run .psqlrc _after_ printing warnings and banner.Bruce Momjian2008-07-18
|
* Fix a race condition that I introduced into sinvaladt.c during the recentTom Lane2008-07-18
| | | | | | | | | rewrite. When called from SIInsertDataEntries, SICleanupQueue releases the write lock if it has to issue a kill() to signal some laggard backend. That still seems like a good idea --- but it's possible that by the time we get the lock back, there are no longer enough free message slots to satisfy SIInsertDataEntries' requirement. Must recheck, and repeat the whole SICleanupQueue process if not. Noted while reading code.
* Suppress compiler warning, and not incidentally make the code moreTom Lane2008-07-18
| | | | | robust. The previous coding was quite risky because it was testing conditions different from 'is the array really allocated?'.
* Implement SQL-spec RETURNS TABLE syntax for functions.Tom Lane2008-07-18
| | | | | | | (Unlike the original submission, this patch treats TABLE output parameters as being entirely equivalent to OUT parameters -- tgl) Pavel Stehule
* Add URL for:Bruce Momjian2008-07-18
| | | | | | * Implement SQL:2003 window functions > http://archives.postgresql.org/pgsql-hackers/2008-07/msg00232.php
* Add MSVC++ debug libraries to .cvsignore.Alvaro Herrera2008-07-17
|
* Avoid crashing when a table is deleted while we're on the process of checkingAlvaro Herrera2008-07-17
| | | | | | it. Per report from Tom Lane based on buildfarm evidence.
* Add dump support for SortBy nodes. Needed this while debugging a reportedTom Lane2008-07-17
| | | | problem with DISTINCT, so might as well commit it.
* Add to TODO:Bruce Momjian2008-07-17
| | | | | | | | > > * Reduce locking requirements for creating a trigger > > http://archives.postgresql.org/pgsql-hackers/2008-06/msg00635.php >
* Add URL for:Bruce Momjian2008-07-16
| | | | | | | * Implement SQL:2003 window functions > > http://archives.postgresql.org/pgsql-hackers/2008-06/msg00380.php >
* Fix previous patch so that it actually works --- consider TRUNCATE foo, ↵Tom Lane2008-07-16
| | | | public.foo
* Add a "provariadic" column to pg_proc to eliminate the remarkably expensiveTom Lane2008-07-16
| | | | | | | | | | need to deconstruct proargmodes for each pg_proc entry inspected by FuncnameGetCandidates(). Fixes function lookup performance regression caused by yesterday's variadic-functions patch. In passing, make pg_proc.probin be NULL, rather than a dummy value '-', in cases where it is not actually used for the particular type of function. This should buy back some of the space cost of the extra column.
* Allow TRUNCATE foo, foo to succeed, per report from Nikhils.Bruce Momjian2008-07-16
|
* Add to TODO:Bruce Momjian2008-07-16
| | | | | | | | > > o Add external tool to auto-tune some postgresql.conf parameters > > http://archives.postgresql.org/pgsql-hackers/2008-06/msg00000.php >
* Support "variadic" functions, which can accept a variable number of argumentsTom Lane2008-07-16
| | | | | | | | | | | | | | so long as all the trailing arguments are of the same (non-array) type. The function receives them as a single array argument (which is why they have to all be the same type). It might be useful to extend this facility to aggregates, but this patch doesn't do that. This patch imposes a noticeable slowdown on function lookup --- a follow-on patch will fix that by adding a redundant column to pg_proc. Pavel Stehule
* Add array_fill() to create arrays initialized with a value.Bruce Momjian2008-07-16
| | | | Pavel Stehule
generated by cgit v1.2.3 (git 2.25.1) at 2025-07-16 06:30:14 +0000