- 12 4月, 2008 5 次提交
-
-
由 Bruce Momjian 提交于
< * Allow functions to control the transaction state > * Allow calling of a procedure outside a SELECT that can control the > transaction state
-
由 Bruce Momjian 提交于
< * Support procedures, which return no value > * Allow functions to control the transaction state
-
由 Bruce Momjian 提交于
> * Support procedures, which return no value > > http://archives.postgresql.org/pgsql-hackers/2007-10/msg01375.php
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
Brendan Jurd
-
- 11 4月, 2008 3 次提交
-
-
由 Tom Lane 提交于
indexscan always occurs in one call, and the results are returned in a TIDBitmap instead of a limited-size array of TIDs. This should improve speed a little by reducing AM entry/exit overhead, and it is necessary infrastructure if we are ever to support bitmap indexes. In an only slightly related change, add support for TIDBitmaps to preserve (somewhat lossily) the knowledge that particular TIDs reported by an index need to have their quals rechecked when the heap is visited. This facility is not really used yet; we'll need to extend the forced-recheck feature to plain indexscans before it's useful, and that hasn't been coded yet. The intent is to use it to clean up 8.3's horrid @@@ kluge for text search with weighted queries. There might be other uses in future, but that one alone is sufficient reason. Heikki Linnakangas, with some adjustments by me.
-
由 Bruce Momjian 提交于
> http://archives.postgresql.org/pgsql-hackers/2007-03/msg00265.php > http://archives.postgresql.org/pgsql-hackers/2007-03/msg01214.php > http://archives.postgresql.org/pgsql-patches/2007-05/msg00013.php > http://archives.postgresql.org/pgsql-hackers/2007-07/msg00741.php > http://archives.postgresql.org/pgsql-hackers/2007-08/msg00014.php > http://archives.postgresql.org/pgsql-hackers/2007-08/msg00487.php > * Allow index scans to return matching index keys > > http://archives.postgresql.org/pgsql-hackers/2007-03/msg01079.php > > http://archives.postgresql.org/pgsql-patches/2007-10/msg00166.php > http://archives.postgresql.org/pgsql-patches/2008-01/msg00049.php
-
由 Magnus Hagander 提交于
on win32, because the stat() function in the runtime cannot be trusted to always update the st_size field. Per report and research by Sergey Zubkovsky.
-
- 10 4月, 2008 4 次提交
-
-
由 Magnus Hagander 提交于
the prototype. Silences msvc build warning.
-
由 Alvaro Herrera 提交于
-
由 Alvaro Herrera 提交于
to the monitoring section. Jim Nasby
-
由 Michael Meskes 提交于
-
- 09 4月, 2008 7 次提交
-
-
由 Bruce Momjian 提交于
you can't get a simultaneous snapshot.
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
seems unnecessary to mention in the FAQ, per discussion on IRC.
-
由 Tom Lane 提交于
the columns it works with to be domains over the expected type, not just exactly the expected type. In passing, fix ts_stat() the same way. Per report from Markus Wollny.
-
- 08 4月, 2008 3 次提交
-
-
由 Peter Eisentraut 提交于
Should fix regression test failures on those platforms.
-
由 Magnus Hagander 提交于
default as other platforms.
-
由 Peter Eisentraut 提交于
Should fix build failures on AIX.
-
- 07 4月, 2008 5 次提交
-
-
由 Peter Eisentraut 提交于
modules are built. Foremost, it creates a solid distinction between these two types of targets based on what had already been implemented and duplicated in ad hoc ways before. Specifically, - Dynamically loadable modules no longer get a soname. The numbers previously set in the makefiles were dummy numbers anyway, and the presence of a soname upset a few packaging tools, so it is nicer not to have one. - The cumbersome detour taken on installation (build a libfoo.so.0.0.0 and then override the rule to install foo.so instead) is removed. - Lots of duplicated code simplified.
-
由 Bruce Momjian 提交于
> > o Add ability to obfuscate function bodies > > http://archives.postgresql.org/pgsql-patches/2008-01/msg00125.php
-
由 Bruce Momjian 提交于
expressions.
-
由 Tom Lane 提交于
for improved compatibility with Oracle. Pavel Stehule, with some fixes by me.
-
由 Tom Lane 提交于
data. This makes for a significant speedup at the cost that the results now vary between little-endian and big-endian machines; which forces us to add explicit ORDER BYs in a couple of regression tests to preserve machine-independent comparison results. Also, force initdb by bumping catversion, since the contents of hash indexes will change (at least on big-endian machines). Kenneth Marshall and Tom Lane, based on work from Bob Jenkins. This commit does not adopt Bob's new faster mix() algorithm, however, since we still need to convince ourselves that that doesn't degrade the quality of the hashing.
-
- 05 4月, 2008 11 次提交
-
-
由 Tom Lane 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Tom Lane 提交于
currently support this because we must be able to build Vars referencing join columns, and varattno is only 16 bits wide. Perhaps this should be improved in future, but considering that it never came up before, I'm not sure the problem is worth much effort. Per bug #4070 from Marcello Ceschia. The problem seems largely academic in 8.0 and 7.4, because they have (different) O(N^2) performance issues with such wide joins, but back-patch all the way anyway.
-
由 Bruce Momjian 提交于
returing right away. This guarantees that when pg_stop_backup() returns, you have a valid backup. Simon Riggs
-
由 Tom Lane 提交于
algorithm. This is a good deal slower than our old roundoff-error-prone code for long inputs, so we keep the old code for use in the transcendental functions, where everything is approximate anyway. Also create a user-accessible function div(numeric, numeric) to provide access to the exact result of trunc(x/y) --- since the regular numeric / operator will round off its result, simply computing that expression in SQL doesn't reliably give the desired answer. This fixes bug #3387 and various related corner cases, and improves the usefulness of PG for high-precision integer arithmetic.
-
由 Bruce Momjian 提交于
Greg Sabino Mullane
-
由 Bruce Momjian 提交于
Greg Sabino Mullane
-
由 Tom Lane 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
At the same time remove dblink/dblink_current_query() as it is no longer necessary *BACKWARD COMPATIBILITY ISSUE* for dblink Tomas Doran
-
- 04 4月, 2008 2 次提交
-
-
由 Magnus Hagander 提交于
a make clean...
-
由 Magnus Hagander 提交于
-