- 08 Jan, 2011 2 commits
-
-
Tom Lane authored
Add more "internal" arguments so that these pg_proc entries reflect the current preferred API. This is purely a cosmetic change, since GIN doesn't actually consult the pg_proc entry when calling a support function. Accordingly, no catversion bump.
-
Tom Lane authored
Per my recent proposal(s). Null key datums can now be returned by extractValue and extractQuery functions, and will be stored in the index. Also, placeholder entries are made for indexable items that are NULL or contain no keys according to extractValue. This means that the index is now always complete, having at least one entry for every indexed heap TID, and so we can get rid of the prohibition on full-index scans. A full-index scan is implemented much the same way as partial-match scans were already: we build a bitmap representing all the TIDs found in the index, and then drive the results off that. Also, introduce a concept of a "search mode" that can be requested by extractQuery when the operator requires matching to empty items (this is just as cheap as matching to a single key) or requires a full index scan (which is not so cheap, but it sure beats failing or giving wrong answers). The behavior remains backward compatible for opclasses that don't return any null keys or request a non-default search mode. Using these features, we can now make the GIN index opclass for anyarray behave in a way that matches the actual anyarray operators for &&, <@, @>, and = ... which it failed to do before in assorted corner cases. This commit fixes the core GIN code and ginarrayprocs.c, updates the documentation, and adds some simple regression test cases for the new behaviors using the array operators. The tsearch and contrib GIN opclass support functions still need to be looked over and probably fixed. Another thing I intend to fix separately is that this is pretty inefficient for cases where more than one scan condition needs a full-index search: we'll run duplicate GinScanEntrys, each one of which builds a large bitmap. There is some existing logic to merge duplicate GinScanEntrys but it needs refactoring to make it work for entries belonging to different scan keys. Note that most of gin.h has been split out into a new file gin_private.h, so that gin.h doesn't export anything that's not supposed to be used by GIN opclasses or the rest of the backend. I did quite a bit of other code beautification work as well, mostly fixing comments and choosing more appropriate names for things.
-
- 07 Jan, 2011 4 commits
-
-
Robert Haas authored
Itagaki Takahiro, edited by me.
-
Robert Haas authored
Jehan-Guillaume de Rorthais, with some additional wordsmithing by me.
-
Itagaki Takahiro authored
Itagaki Takahiro and Simon Riggs.
-
Bruce Momjian authored
functions.
-
- 06 Jan, 2011 5 commits
-
-
Peter Eisentraut authored
-
Peter Eisentraut authored
The previous example didn't make it clear whether array_upper returned the last element or the index of the last element.
-
Tom Lane authored
-
Bruce Momjian authored
lo_insert.
-
Bruce Momjian authored
-
- 05 Jan, 2011 8 commits
-
-
Bruce Momjian authored
-
Bruce Momjian authored
handling. (metadata user ids still an open issue).
-
Bruce Momjian authored
-
Bruce Momjian authored
up pg_dump's calling of pg_upgrade_support functions.
-
Magnus Hagander authored
This can be overriden by using NOREPLICATION on the CREATE ROLE statement, but by default they will have it, making it backwards compatible and "less surprising" (given that superusers normally override all checks).
-
Bruce Momjian authored
servers because, like pg_largeobject, it is a system table whose contents are not dumped by pg_dump --schema-only.
-
Bruce Momjian authored
-
Bruce Momjian authored
-
- 04 Jan, 2011 2 commits
-
-
Itagaki Takahiro authored
Missing support for VALID UNTIL in CREATE ROLE is also added.
-
Robert Haas authored
In the previous coding, the parser emitted a List containing a C string, which is no good, because copyObject() can't handle it. Dimitri Fontaine
-
- 03 Jan, 2011 5 commits
-
-
Robert Haas authored
-
Magnus Hagander authored
-
Magnus Hagander authored
Add the view pg_stat_database_conflicts and a column to pg_stat_database, and the underlying functions to provide the information.
-
Magnus Hagander authored
Noted by Peter E.
-
Magnus Hagander authored
Forgot this with previuos commit, line it up so it's easier to submit (readable) patches against the MSVC build system.
-
- 02 Jan, 2011 3 commits
-
-
Peter Eisentraut authored
Add new function pg_sequence_parameters that returns a sequence's start, minimum, maximum, increment, and cycle values, and use that in the view. (bug #5662; design suggestion by Tom Lane) Also slightly adjust the view's column order and permissions after review of SQL standard.
-
Robert Haas authored
Noted by Magnus Hagander.
-
Robert Haas authored
Foreign tables are a core component of SQL/MED. This commit does not provide a working SQL/MED infrastructure, because foreign tables cannot yet be queried. Support for foreign table scans will need to be added in a future patch. However, this patch creates the necessary system catalog structure, syntax support, and support for ancillary operations such as COMMENT and SECURITY LABEL. Shigeru Hanada, heavily revised by Robert Haas
-
- 01 Jan, 2011 8 commits
-
-
Robert Haas authored
As suggested by Tom Lane, in response to a gripe from Leslie S Satenstein.
-
Robert Haas authored
Along the way, correct an erroneous comment.
-
Peter Eisentraut authored
This is analogous to the existing facility that allows casting a row type to a supertable's row type.
-
Bruce Momjian authored
-
Bruce Momjian authored
-
Bruce Momjian authored
-
Bruce Momjian authored
pointers, which simplifies the code. This was not possible in 9.0 because everything was in a single nested struct, but is possible now. Per suggestion from Tom.
-
Bruce Momjian authored
-
- 31 Dec, 2010 3 commits
-
-
Bruce Momjian authored
"wait" detection and add postmaster start time to help determine if the postmaster is actually using the specified data directory.
-
Tom Lane authored
No change in functionality. Per discussion with Robert.
-
Tom Lane authored
There's no reason for these values to be known anywhere else. After doing this, executor/execdefs.h is vestigial and can be removed.
-