- 30 12月, 2009 1 次提交
-
-
由 Heikki Linnakangas 提交于
PL/pgSQL function within an exception handler. Make sure we use the right resource owner when we create the tuplestore to hold returned tuples. Simplify tuplestore API so that the caller doesn't need to be in the right memory context when calling tuplestore_put* functions. tuplestore.c automatically switches to the memory context used when the tuplestore was created. Tuplesort was already modified like this earlier. This patch also removes the now useless MemoryContextSwitch calls from callers. Report by Aleksei on pgsql-bugs on Dec 22 2009. Backpatch to 8.1, like the previous patch that broke this.
-
- 29 12月, 2009 4 次提交
-
-
由 Peter Eisentraut 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
libraries can access them.
-
由 Bruce Momjian 提交于
-
- 28 12月, 2009 4 次提交
-
-
由 Tom Lane 提交于
The temporary hash tables made by pgstat_collect_oids should be allocated in a short-term memory context, which is not the default behavior of hash_create. Noted while looking through hash_create calls in connection with Robert Haas' recent complaint. This is a pre-existing bug, but it doesn't seem important enough to back-patch. The hash table is not so large that it would matter unless this happened many times within a session, which seems quite unlikely.
-
由 Tom Lane 提交于
probably got there via blind copy-and-paste from one of the legitimate callers, so rearrange and comment that code a bit to make it clearer that this isn't a necessary prerequisite to hash_create. Per observation from Robert Haas.
-
由 Magnus Hagander 提交于
-
由 Magnus Hagander 提交于
system and local environments anyway, instead of aborting. (This will happen in a MSVC build with no or very few external libraries linked in)
-
- 27 12月, 2009 2 次提交
-
-
由 Bruce Momjian 提交于
use in binary upgrades. Bump catalog version for detection by pg_migrator of new backend API.
-
由 Bruce Momjian 提交于
Allow enums to be created with zero labels, for use during binary upgrade.
-
- 26 12月, 2009 1 次提交
-
-
由 Tom Lane 提交于
restrict list is not just something to ignore, it's actually grounds to abandon the optimization entirely. Per bug #5255 from Matteo Beccati.
-
- 25 12月, 2009 6 次提交
-
-
由 Robert Haas 提交于
of HS-related parameters. Fujii Masao
-
由 Andrew Dunstan 提交于
-
由 Tom Lane 提交于
commands, as per recent discussion. Includes suggestions from Adrian Klaver and Filip Rembialkowski.
-
由 Bruce Momjian 提交于
variable names.
-
由 Bruce Momjian 提交于
Modify pg_dump --binary-upgrade and add backend support routines to support the preservation of pg_type oids when doing a binary upgrade. This allows user-defined composite types and arrays to be binary upgraded.
-
由 Tom Lane 提交于
index page split. This would result in index corruption, or even more likely an error during WAL replay, if we were unlucky enough to crash during end-of-recovery cleanup after having completed an incomplete GIST insertion. Yoichi Hirai
-
- 24 12月, 2009 4 次提交
-
-
由 Peter Eisentraut 提交于
Instead, add a few targets that were missing.
-
由 Peter Eisentraut 提交于
also works transparently for lesser used targets.
-
由 Tom Lane 提交于
choose an index name the same as it would do for an unnamed index constraint. (My recent changes to the index naming logic have helped to ensure that this will be a reasonable choice.) Per a suggestion from Peter. A necessary side-effect is to promote CONCURRENTLY to type_func_name_keyword status, ie, it can't be a table/column/index name anymore unless quoted. This is not all bad, since we have heard more than once of people typing CREATE INDEX CONCURRENTLY ON foo (...) and getting a normal index build of an index named "concurrently", which was not what they wanted. Now this syntax will result in a concurrent build of an index with system-chosen name; which they can rename afterwards if they want something else.
-
由 Tom Lane 提交于
their underlying table columns. That code was not bright enough to cope with collision situations (ie, new name conflicts with some other column of the index). Since there is no functional reason to do this at all, trying to upgrade the logic to be bulletproof doesn't seem worth the trouble. This change means that both the index name and the column names of an index are set when it's created, and won't be automatically changed when the underlying table columns are renamed. Neatnik DBAs are still free to rename them manually, of course.
-
- 23 12月, 2009 6 次提交
-
-
由 Magnus Hagander 提交于
generating the build files for 2005 and then converting them.
-
由 Heikki Linnakangas 提交于
CREATE FOREIGN DATA WRAPPER. Arguably it wasn't a bug because the documentation said that it's passed the catalog ID or zero, but surely we should provide it when it's known. And there isn't currently any scenario where it's not known, and I can't imagine having one in the future either, so better remove the "or zero" escape hatch and always pass a valid catalog ID. Backpatch to 8.4. Martin Pihlak
-
由 Bruce Momjian 提交于
-
由 Tom Lane 提交于
Index expression columns are now named after the FigureColname result for their expressions, rather than always being "pg_expression_N". Digits are appended to this name if needed to make the column name unique within the index. (That happens for regular columns too, thus fixing the old problem that CREATE INDEX fooi ON foo (f1, f1) fails. Before exclusion indexes there was no real reason to do such a thing, but now maybe there is.) Default names for indexes and associated constraints now include the column names of all their columns, not only the first one as in previous practice. (Of course, this will be truncated as needed to fit in NAMEDATALEN. Also, pkey indexes retain the historical behavior of not naming specific columns at all.) An example of the results: regression=# create table foo (f1 int, f2 text, regression(# exclude (f1 with =, lower(f2) with =)); NOTICE: CREATE TABLE / EXCLUDE will create implicit index "foo_f1_lower_exclusion" for table "foo" CREATE TABLE regression=# \d foo_f1_lower_exclusion Index "public.foo_f1_lower_exclusion" Column | Type | Definition --------+---------+------------ f1 | integer | f1 lower | text | lower(f2) btree, for table "public.foo"
-
由 Tom Lane 提交于
and composite types, which are the only relkinds for which pg_dump support exists for dumping column comments. There is no obvious usefulness for comments on columns of sequences or toast tables; and while comments on index columns might have some value, it's not worth the risk of compatibility problems due to possible changes in the algorithm for assigning names to index columns. Per discussion. In consequence, remove now-dead code for copying such comments in CREATE TABLE LIKE.
-
由 Peter Eisentraut 提交于
-
- 21 12月, 2009 2 次提交
-
-
由 Robert Haas 提交于
Rewrite or adjust various comments for clarity. Remove one bogus comment that doesn't reflect what the code actually does. Improve the description of the lo_compat_privileges option.
-
由 Tom Lane 提交于
have hard-wired knowledge of the rules for naming index columns. It can just look at the actual names in the source index, instead. Do some minor formatting cleanup too.
-
- 20 12月, 2009 5 次提交
-
-
由 Robert Haas 提交于
John Naylor
-
由 Peter Eisentraut 提交于
function body can have undesirable outcomes. (bug #5232)
-
由 Peter Eisentraut 提交于
-
由 Peter Eisentraut 提交于
-
由 Bruce Momjian 提交于
-
- 19 12月, 2009 5 次提交
-
-
由 Tom Lane 提交于
-
由 Itagaki Takahiro 提交于
PL/pgSQL-by-default patch broke the code for 8.3 <= server_version < 8.5.
-
由 Tom Lane 提交于
contents, and PG_CONTROL_VERSION to reflect the fact that it changed pg_control contents. (I see we did at least remember to change XLOG_PAGE_MAGIC for the WAL contents changes.)
-
由 Itagaki Takahiro 提交于
-
由 Tom Lane 提交于
-