- 28 10月, 2009 1 次提交
-
-
由 Tom Lane 提交于
for example in WITH w AS (SELECT * FROM foo) SELECT * FROM w, bar ... FOR UPDATE the FOR UPDATE will now affect bar but not foo. This is more useful and consistent than the original 8.4 behavior, which tried to propagate FOR UPDATE into the WITH query but always failed due to assorted implementation restrictions. Even though we are in process of removing those restrictions, it seems correct on philosophical grounds to not let the outer query's FOR UPDATE affect the WITH query. In passing, fix isLockedRel which frequently got things wrong in nested-subquery cases: "FOR UPDATE OF foo" applies to an alias foo in the current query level, not subqueries. This has been broken for a long time, but it doesn't seem worth back-patching further than 8.4 because the actual consequences are minimal. At worst the parser would sometimes get RowShareLock on a relation when it should be AccessShareLock or vice versa. That would only make a difference if someone were using ExclusiveLock concurrently, which no standard operation does, and anyway FOR UPDATE doesn't result in visible changes so it's not clear that the someone would notice any problem. Between that and the fact that FOR UPDATE barely works with subqueries at all in existing releases, I'm not excited about worrying about it.
-
- 27 10月, 2009 4 次提交
-
-
由 Alvaro Herrera 提交于
Per note from Zoltan Boszormenyi.
-
由 Peter Eisentraut 提交于
files in one run.
-
由 Peter Eisentraut 提交于
-
由 Heikki Linnakangas 提交于
those accepted by date_in(). I confused julian day numbers and number of days since the postgres epoch 2000-01-01 in the original patch. I just noticed that it's still easy to get such out-of-range values into the database using to_date or +- operators, but this patch doesn't do anything about those functions. Per report from James Pye.
-
- 26 10月, 2009 1 次提交
-
-
由 Tom Lane 提交于
a lot of strange behaviors that occurred in join cases. We now identify the "current" row for every joined relation in UPDATE, DELETE, and SELECT FOR UPDATE/SHARE queries. If an EvalPlanQual recheck is necessary, we jam the appropriate row into each scan node in the rechecking plan, forcing it to emit only that one row. The former behavior could rescan the whole of each joined relation for each recheck, which was terrible for performance, and what's much worse could result in duplicated output tuples. Also, the original implementation of EvalPlanQual could not re-use the recheck execution tree --- it had to go through a full executor init and shutdown for every row to be tested. To avoid this overhead, I've associated a special runtime Param with each LockRows or ModifyTable plan node, and arranged to make every scan node below such a node depend on that Param. Thus, by signaling a change in that Param, the EPQ machinery can just rescan the already-built test plan. This patch also adds a prohibition on set-returning functions in the targetlist of SELECT FOR UPDATE/SHARE. This is needed to avoid the duplicate-output-tuple problem. It seems fairly reasonable since the other restrictions on SELECT FOR UPDATE are meant to ensure that there is a unique correspondence between source tuples and result tuples, which an output SRF destroys as much as anything else does.
-
- 23 10月, 2009 1 次提交
-
-
由 Peter Eisentraut 提交于
child tables. This was found to be useless and confusing in virtually all cases, and also contrary to the SQL standard.
-
- 22 10月, 2009 3 次提交
-
-
由 Tom Lane 提交于
style by default. Per discussion, there seems to be hardly anything that really relies on being able to change the regex flavor, so the ability to select it via embedded options ought to be enough for any stragglers. Also, if we didn't remove the GUC, we'd really be morally obligated to mark the regex functions non-immutable, which'd possibly create performance issues.
-
由 Tom Lane 提交于
Per recent discussion, add_missing_from has been deprecated for long enough to consider removing, and it's getting in the way of planned parser refactoring. The system now always behaves as though add_missing_from were OFF.
-
由 Peter Eisentraut 提交于
-
- 21 10月, 2009 3 次提交
-
-
由 Peter Eisentraut 提交于
-
由 Peter Eisentraut 提交于
-
由 Peter Eisentraut 提交于
made to automatically exclude translations below the 80% minimum.
-
- 17 10月, 2009 3 次提交
-
-
由 Magnus Hagander 提交于
by me.
-
由 Magnus Hagander 提交于
as necessary. Itagaki Takahiro with some changes from me
-
由 Tom Lane 提交于
pam_message array contains exactly one PAM_PROMPT_ECHO_OFF message. Instead, deal with however many messages there are, and don't throw error for PAM_ERROR_MSG and PAM_TEXT_INFO messages. This logic is borrowed from openssh 5.2p1, which hopefully has seen more real-world PAM usage than we have. Per bug #5121 from Ryan Douglas, which turned out to be caused by the conv_proc being called with zero messages. Apparently that is normal behavior given the combination of Linux pam_krb5 with MS Active Directory as the domain controller. Patch all the way back, since this code has been essentially untouched since 7.4. (Surprising we've not heard complaints before.)
-
- 16 10月, 2009 2 次提交
-
-
由 Heikki Linnakangas 提交于
vacuumdb produces. Per report by Thom Brown.
-
由 Tom Lane 提交于
required \200 bytes. Let's see if this commit works, or if CVS is messing it up.
-
- 15 10月, 2009 6 次提交
-
-
由 Michael Meskes 提交于
patch send in by Boszormenyi Zoltan <zb@cybertec.at>.
-
由 Alvaro Herrera 提交于
Author: Martin Pihlak
-
由 Tom Lane 提交于
are named in the UPDATE's SET list. Note: the schema of pg_trigger has not actually changed; we've just started to use a column that was there all along. catversion bumped anyway so that this commit is included in the history of potentially interesting changes to system catalog contents. Itagaki Takahiro
-
由 Heikki Linnakangas 提交于
to make it more obvious that it's a PostgreSQL internal limit, not something that comes from system header files.
-
由 Peter Eisentraut 提交于
shell construct to hide away the stderr output. Python 3.1 actually core dumps on the current invocation (http://bugs.python.org/issue7111), but the new version also has the more general advantage of saving the error message in config.log for analysis.
-
由 Peter Eisentraut 提交于
-
- 14 10月, 2009 3 次提交
-
-
由 Heikki Linnakangas 提交于
and SSPI athentication methods. While the old 2000 byte limit was more than enough for Unix Kerberos implementations, tickets issued by Windows Domain Controllers can be much larger. Ian Turner
-
由 Peter Eisentraut 提交于
-
由 Tom Lane 提交于
ASCII-art style of table output to be upgraded to use Unicode box drawing characters if desired. By default, psql will use the Unicode characters whenever client_encoding is UTF8. The patch forces linestyle=ascii in pg_regress usage, ensuring we don't break the regression tests in Unicode locales. Roger Leigh
-
- 13 10月, 2009 7 次提交
-
-
由 Tom Lane 提交于
Also insert a couple of Asserts that check for stack overflow. Bogus coding appears to be new in 8.4 --- older releases had a much simpler algorithm here. Per bug #5111.
-
由 Alvaro Herrera 提交于
last week. Per note and patch from Jeff Davis.
-
由 Tom Lane 提交于
so cosmetic stuff.
-
由 Tom Lane 提交于
the keywords as a consequence of the GRANT ALL patch, so we might as well use them and make the ALTER commands read more naturally.
-
由 Tom Lane 提交于
Petr Jelinek
-
由 Andrew Dunstan 提交于
-
由 Tom Lane 提交于
execMain.c and into a new plan node type LockRows. Like the recent change to put table updating into a ModifyTable plan node, this increases planning flexibility by allowing the operations to occur below the top level of the plan tree. It's necessary in any case to restore the previous behavior of having FOR UPDATE locking occur before ModifyTable does. This partially refactors EvalPlanQual to allow multiple rows-under-test to be inserted into the EPQ machinery before starting an EPQ test query. That isn't sufficient to fix EPQ's general bogosity in the face of plans that return multiple rows per test row, though. Since this patch is mostly about getting some plan node infrastructure in place and not about fixing ten-year-old bugs, I will leave EPQ improvements for another day. Another behavioral change that we could now think about is doing FOR UPDATE before LIMIT, but that too seems like it should be treated as a followon patch.
-
- 10 10月, 2009 3 次提交
-
-
由 Tom Lane 提交于
* Stop escaping ? and {. As of SQL:2008, SIMILAR TO is defined to have POSIX-compatible interpretation of ? as well as {m,n} and related constructs, so we should allow these things through to our regex engine. * Escape ^ and $. It appears that our regex engine will treat ^^ at the beginning of the string the same as ^, and similarly for $$ at the end of the string, which meant that SIMILAR TO was effectively ignoring ^ at the start of the pattern and $ at the end. Since these are not supposed to be metacharacters, this is a bug. The second part of this is arguably a back-patchable bug fix, but I'm hesitant to do that because it might break applications that are expecting something like "col SIMILAR TO '^foo$'" to work like a POSIX pattern. Seems safer to only change it at a major version boundary. Per discussion of an example from Doug Gorley.
-
由 Tom Lane 提交于
They are now handled by a new plan node type called ModifyTable, which is placed at the top of the plan tree. In itself this change doesn't do much, except perhaps make the handling of RETURNING lists and inherited UPDATEs a tad less klugy. But it is necessary preparation for the intended extension of allowing RETURNING queries inside WITH. Marko Tiikkaja
-
由 Peter Eisentraut 提交于
Add a variant of pg_get_triggerdef with a second argument "pretty" that causes the output to be formatted in the way pg_dump used to do. Use this variant in pg_dump with server versions >= 8.5. This insulates pg_dump from most future trigger feature additions, such as the upcoming column triggers patch. Author: Itagaki Takahiro <itagaki.takahiro@oss.ntt.co.jp>
-
- 09 10月, 2009 2 次提交
-
-
由 Tom Lane 提交于
friends). This code has all been ifdef'd out for many years, and doesn't seem to have any prospect of becoming any more useful in the future. EXPLAIN ANALYZE is what people use in practice, and I think if we did want process-wide counters we'd be more likely to put in dtrace events for that than try to resurrect this code. Get rid of it so as to have one less detail to worry about while refactoring execMain.c.
-
由 Alvaro Herrera 提交于
I also thank Bernd Helmle for the documentation help on the previous settings patch, which I forgot on the commit message.
-
- 08 10月, 2009 1 次提交
-
-
由 Heikki Linnakangas 提交于
8, bitncmp() may dereference a pointer one byte out of bounds. Chris Mikkelson (bug #5101)
-