- 18 9月, 2009 1 次提交
-
-
由 Peter Eisentraut 提交于
Instead of requiring translators to translate the entire SQL command synopses, change create_help.pl to only require them to translate the placeholders, and paste those into the synopsis using a printf mechanism. Make some small updates to the markup to make it easier to parse. Note: This causes msgmerge of gettext 0.17 to segfault. You will need the patch from https://savannah.gnu.org/bugs/?27474 to make it work. msgmerge usually only runs on babel.postgresql.org, however.
-
- 28 8月, 2009 1 次提交
-
-
由 Tom Lane 提交于
so that their elements are always taken as simple expressions over the query's input columns. It originally seemed like a good idea to make them act exactly like GROUP BY and ORDER BY, right down to the SQL92-era behavior of accepting output column names or numbers. However, that was not such a great idea, for two reasons: 1. It permits circular references, as exhibited in bug #5018: the output column could be the one containing the window function itself. (We actually had a regression test case illustrating this, but nobody thought twice about how confusing that would be.) 2. It doesn't seem like a good idea for, eg, "lead(foo) OVER (ORDER BY foo)" to potentially use two completely different meanings for "foo". Accordingly, narrow down the behavior of window clauses to use only the SQL99-compliant interpretation that the expressions are simple expressions.
-
- 19 8月, 2009 1 次提交
-
-
由 Tom Lane 提交于
about it doesn't simplify the grammar at all, and it does invite confusion among those who only read the SELECT syntax summary and not the full details. Per gripe from Jaime Casanova.
-
- 04 5月, 2009 1 次提交
-
-
由 Tom Lane 提交于
a parenthetical remark.
-
- 16 4月, 2009 1 次提交
-
-
由 Bruce Momjian 提交于
mentions in main documentation.
-
- 03 2月, 2009 1 次提交
-
-
由 Tom Lane 提交于
per gripe from David Wheeler that this was mentioned nowhere. In passing, editorialize a bit on the description of the SQL:2008 equivalent syntax.
-
- 23 1月, 2009 2 次提交
-
-
由 Bruce Momjian 提交于
results out of order because of locking, per bug report 4593
-
由 Tom Lane 提交于
Stephen Frost, with help from KaiGai Kohei and others
-
- 12 1月, 2009 1 次提交
-
-
由 Peter Eisentraut 提交于
after ONLY.
-
- 01 1月, 2009 1 次提交
-
-
由 Tom Lane 提交于
frame clause, as appears to be required by the fine print in the SQL spec. Per discussion with Pavel, not doing so risks user confusion.
-
- 31 12月, 2008 1 次提交
-
-
由 Tom Lane 提交于
patch. This includes the ability to force the frame to cover the whole partition, and the ability to make the frame end exactly on the current row rather than its last ORDER BY peer. Supporting any more of the full SQL frame-clause syntax will require nontrivial hacking on the window aggregate code, so it'll have to wait for 8.5 or beyond.
-
- 30 12月, 2008 1 次提交
-
-
由 Tom Lane 提交于
per Hitoshi Harada.
-
- 29 12月, 2008 1 次提交
-
-
由 Tom Lane 提交于
Hitoshi Harada, with some kibitzing from Heikki and Tom.
-
- 01 12月, 2008 1 次提交
-
-
由 Peter Eisentraut 提交于
-
- 21 11月, 2008 1 次提交
-
-
由 Peter Eisentraut 提交于
-
- 20 11月, 2008 1 次提交
-
-
由 Peter Eisentraut 提交于
-
- 19 11月, 2008 1 次提交
-
-
由 Peter Eisentraut 提交于
Now "\help WITH" works and there will be a separate WITH(7) man page.
-
- 14 11月, 2008 1 次提交
-
-
由 Peter Eisentraut 提交于
another section if required by the platform (instead of the old way of building them in section "l" and always transforming them to the platform-specific section). This speeds up the installation on common platforms, and it avoids some funny business with the man page tools and build process.
-
- 22 10月, 2008 1 次提交
-
-
由 Peter Eisentraut 提交于
OFFSET num {ROW|ROWS} FETCH {FIRST|NEXT} [num] {ROW|ROWS} ONLY
-
- 08 10月, 2008 1 次提交
-
-
由 Tom Lane 提交于
implementation uses an in-memory hash table, so it will poop out for very large recursive results ... but the performance characteristics of a sort-based implementation would be pretty unpleasant too.
-
- 05 10月, 2008 1 次提交
-
-
由 Tom Lane 提交于
There are some unimplemented aspects: recursive queries must use UNION ALL (should allow UNION too), and we don't have SEARCH or CYCLE clauses. These might or might not get done for 8.4, but even without them it's a pretty useful feature. There are also a couple of small loose ends and definitional quibbles, which I'll send a memo about to pgsql-hackers shortly. But let's land the patch now so we can get on with other development. Yoshiyuki Asaba, with lots of help from Tatsuo Ishii and Tom Lane
-
- 23 9月, 2008 1 次提交
-
-
由 Heikki Linnakangas 提交于
ctype are now more like encoding, stored in new datcollate and datctype columns in pg_database. This is a stripped-down version of Radek Strnad's patch, with further changes by me.
-
- 16 2月, 2008 1 次提交
-
-
由 Tom Lane 提交于
(or RETURNING), but only when the output name is not any SQL keyword. This seems as close as we can get to the standard's syntax without a great deal of thrashing. Original patch by Hiroshi Saito, amended by me.
-
- 28 11月, 2007 1 次提交
-
-
由 Peter Eisentraut 提交于
-
- 09 6月, 2007 1 次提交
-
-
由 Tom Lane 提交于
results. Necessary due to introduction of syncscan patch.
-
- 16 5月, 2007 1 次提交
-
-
由 Neil Conway 提交于
parentheses in syntax descriptions. Consistently use the present tense when describing the basic purpose of each "DROP" command. Add a few more hyperlinks.
-
- 02 2月, 2007 1 次提交
-
-
由 Bruce Momjian 提交于
Standard English uses "may", "can", and "might" in different ways: may - permission, "You may borrow my rake." can - ability, "I can lift that log." might - possibility, "It might rain today." Unfortunately, in conversational English, their use is often mixed, as in, "You may use this variable to do X", when in fact, "can" is a better choice. Similarly, "It may crash" is better stated, "It might crash".
-
- 01 2月, 2007 2 次提交
-
-
由 Bruce Momjian 提交于
appropriate.
-
由 Bruce Momjian 提交于
Standard English uses "may", "can", and "might" in different ways: may - permission, "You may borrow my rake." can - ability, "I can lift that log." might - possibility, "It might rain today." Unfortunately, in conversational English, their use is often mixed, as in, "You may use this variable to do X", when in fact, "can" is a better choice. Similarly, "It may crash" is better stated, "It might crash".
-
- 10 1月, 2007 1 次提交
-
-
由 Tom Lane 提交于
out the common error that ORDER BY x, y DESC does not mean the same as ORDER BY x DESC, y DESC.
-
- 09 1月, 2007 1 次提交
-
-
由 Tom Lane 提交于
per-column options for btree indexes. The planner's support for this is still pretty rudimentary; it does not yet know how to plan mergejoins with nondefault ordering options. The documentation is pretty rudimentary, too. I'll work on improving that stuff later. Note incompatible change from prior behavior: ORDER BY ... USING will now be rejected if the operator is not a less-than or greater-than member of some btree opclass. This prevents less-than-sane behavior if an operator that doesn't actually define a proper sort ordering is selected.
-
- 02 12月, 2006 1 次提交
-
-
由 Tom Lane 提交于
locks that logically should not be released, because when a subtransaction overwrites XMAX all knowledge of the previous lock state is lost. It seems unlikely that we will be able to fix this before 8.3...
-
- 19 9月, 2006 1 次提交
-
-
由 Tom Lane 提交于
-
- 16 9月, 2006 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 01 5月, 2006 1 次提交
-
-
由 Tom Lane 提交于
support both FOR UPDATE and FOR SHARE in one command, as well as both NOWAIT and normal WAIT behavior. The more general code is actually simpler and cleaner.
-
- 02 11月, 2005 1 次提交
-
-
由 Tom Lane 提交于
-
- 02 8月, 2005 1 次提交
-
-
由 Tom Lane 提交于
Original patch by Hans-Juergen Schoenig, revisions by Karel Zak and Tom Lane.
-
- 14 7月, 2005 1 次提交
-
-
由 Neil Conway 提交于
is used as if it were the latest (and/or still valid) SQL standard. SQL:2003 is used in its place. Patch from Simon Riggs.
-
- 08 5月, 2005 1 次提交
-
-
由 Bruce Momjian 提交于
Vladimir Chukharev
-
- 29 4月, 2005 1 次提交
-
-
由 Tom Lane 提交于
to eliminate unnecessary deadlocks. This commit adds SELECT ... FOR SHARE paralleling SELECT ... FOR UPDATE. The implementation uses a new SLRU data structure (managed much like pg_subtrans) to represent multiple- transaction-ID sets. When more than one transaction is holding a shared lock on a particular row, we create a MultiXactId representing that set of transactions and store its ID in the row's XMAX. This scheme allows an effectively unlimited number of row locks, just as we did before, while not costing any extra overhead except when a shared lock actually has to be shared. Still TODO: use the regular lock manager to control the grant order when multiple backends are waiting for a row lock. Alvaro Herrera and Tom Lane.
-