- 11 Mar, 2011 20 commits
-
-
Bruce Momjian authored
-
Bruce Momjian authored
-
Heikki Linnakangas authored
variable hiding. A constant is not a variable. It worked in most cases by accident, because we add constants to the global list of variables (why?), but float constants like 1.23 were interpreted as struct field references, and not found. Backpatch to 9.0, where the test for variable hiding was added.
-
Bruce Momjian authored
Removes extraneous closing parenthesis from pg_describe_object Puts pg_describe_object and has_sequence_privilege in correct alphabetical position in function listing Thom Brown
-
Bruce Momjian authored
-
Bruce Momjian authored
-
Bruce Momjian authored
-
Bruce Momjian authored
Josh Berkus
-
Bruce Momjian authored
-
Bruce Momjian authored
-
Bruce Momjian authored
to fully process errors.
-
Bruce Momjian authored
FREEZE functionality.
-
Bruce Momjian authored
-
Bruce Momjian authored
suggestion.
-
Bruce Momjian authored
backward compatibility.
-
Bruce Momjian authored
-
Bruce Momjian authored
-
Bruce Momjian authored
O_DIRECT behavior.
-
Bruce Momjian authored
opposed to O_DSYNC.
-
Bruce Momjian authored
complex quoting, e.g. -t and -n.
-
- 10 Mar, 2011 20 commits
-
-
Bruce Momjian authored
-
Bruce Momjian authored
-
Bruce Momjian authored
-
Bruce Momjian authored
-
Tom Lane authored
Including collation in the behavior of that function promotes a world view we do not want. Moreover, it was producing the wrong behavior for pg_dump anyway: what we want is to dump a COLLATE clause on attributes whose attcollation is different from the underlying type, and likewise for domains, and the function cannot do that for us. Doing it the hard way in pg_dump is a bit more tedious but produces more correct output. In passing, fix initdb so that the initial entry in pg_collation is properly pinned. It was droppable before :-(
-
Robert Haas authored
It's not a good idea to kill the postmaster just because someone muffs this, and it's not consistent with what we do for other, similar GUCs. Fujii Masao, with a bit more hacking by me
-
Robert Haas authored
Fujii Masao
-
Robert Haas authored
SyncRepRequested() must check not only the value of the synchronous_replication GUC but also whether max_wal_senders > 0. Otherwise, we might end up waiting for sync rep even when there's no possibility of a standby ever managing to connect. There are some existing cross-checks to prevent this, but they're not quite sufficient: the user can start the server with max_wal_senders=0, synchronous_standby_names='', and synchronous_replication=off and then subsequent make synchronous_standby_names not empty using pg_ctl reload, and then SET synchronous_standby=on, leading to an indefinite hang. Along the way, rename the global variable for the synchronous_replication GUC to match the name of the GUC itself, for clarity. Report by Fujii Masao, though I didn't use his patch.
-
Robert Haas authored
In earlier versions of the sync rep patch, waiters removed themselves from the queue, but now walsender removes them before doing the wakeup. Report by Fujii Masao.
-
Robert Haas authored
Fujii Masao, with a bit of additional wordsmithing by me.
-
Robert Haas authored
Fujii Masao
-
Robert Haas authored
Fujii Masao
-
Bruce Momjian authored
-
Robert Haas authored
Fujii Masao
-
Heikki Linnakangas authored
Tom Lane pointed out that it was giving a warning: "-s option given but default rule can be matched". That was because there was no rule to handle newline in a quoted string. I made that throw an error. Also, line number tracking was broken, giving incorrect line number on error. Fixed that too.
-
Itagaki Takahiro authored
-
Tom Lane authored
-
Tom Lane authored
At least two recent commits have apparently imagined that a comment in a Makefile stating that something would be included in the distribution tarball was sufficient to make it so. They hadn't bothered to hook into the upper maintainer-clean targets either. Per bug #5923 from Charles Johnson, in which it emerged that the 9.1alpha4 tarballs are short a few files that should be there.
-
Bruce Momjian authored
-
Tom Lane authored
The initial collations patch treated a COLLATE spec as part of a TypeName, following what can only be described as brain fade on the part of the SQL committee. It's a lot more reasonable to treat COLLATE as a syntactically separate object, so that it can be added in only the productions where it actually belongs, rather than needing to reject it in a boatload of places where it doesn't belong (something the original patch mostly failed to do). In addition this change lets us meet the spec's requirement to allow COLLATE anywhere in the clauses of a ColumnDef, and it avoids unfriendly behavior for constructs such as "foo::type COLLATE collation". To do this, pull collation information out of TypeName and put it in ColumnDef instead, thus reverting most of the collation-related changes in parse_type.c's API. I made one additional structural change, which was to use a ColumnDef as an intermediate node in AT_AlterColumnType AlterTableCmd nodes. This provides enough room to get rid of the "transform" wart in AlterTableCmd too, since the ColumnDef can carry the USING expression easily enough. Also fix some other minor bugs that have crept in in the same areas, like failure to copy recently-added fields of ColumnDef in copyfuncs.c. While at it, document the formerly secret ability to specify a collation in ALTER TABLE ALTER COLUMN TYPE, ALTER TYPE ADD ATTRIBUTE, and ALTER TYPE ALTER ATTRIBUTE TYPE; and correct some misstatements about what the default collation selection will be when COLLATE is omitted. BTW, the three-parameter form of format_type() should go away too, since it just contributes to the confusion in this area; but I'll do that in a separate patch.
-