- 24 10月, 2008 5 次提交
-
-
由 Magnus Hagander 提交于
-
由 Magnus Hagander 提交于
end-user documentation that lives in the actual documentation.
-
由 Magnus Hagander 提交于
to the old set of SSL patches. Hasn't been updated since, and we keep the TODOs in the "real" TODO list, really...
-
由 Magnus Hagander 提交于
of copy/paste:d emails. Much of the contents had already been migrated into the main documentation, some was out of date and some just plain wrong. Keep the "protocol-flowchart" which can still be useful.
-
由 Magnus Hagander 提交于
-
- 23 10月, 2008 7 次提交
-
-
由 Tom Lane 提交于
in their targetlists had better reset ps_TupFromTlist during ReScan calls. There's no need to back-patch here since nodeAgg and nodeGroup didn't even pretend to support SRFs in prior releases.
-
由 Tom Lane 提交于
used long ago, but in the current code the ecxt_outertuple field of ExprContext is doing all the work. Spotted by Ran Tang.
-
由 Magnus Hagander 提交于
* make LDAP use this instead of the hacky previous method to specify the DN to bind as * make all auth options behave the same when they are not compiled into the server * rename "ident maps" to "user name maps", and support them for all auth methods that provide an external username This makes a backwards incompatible change in the format of pg_hba.conf for the ident, PAM and LDAP authentication methods.
-
由 Peter Eisentraut 提交于
(INCLUDING/EXCLUDING DEFAULTS)
-
由 Peter Eisentraut 提交于
-
由 Tom Lane 提交于
inputs is unique or nearly so), make eqjoinsel() clamp the ndistinct estimates to be not more than the estimated number of rows coming from the input relations. This allows the estimate to change in response to the selectivity of restriction conditions on the inputs. This is a pretty narrow patch and maybe we should be more aggressive about similarly clamping ndistinct in other cases; but I'm worried about double-counting the effects of the restriction conditions. However, it seems to help for the case exhibited by Grzegorz Jaskiewicz (antijoin against a small subset of a relation), so let's try this for awhile.
-
由 Tom Lane 提交于
until vars are distributed to rels during query_planner() startup. We don't really need it before that, and not building it early has some advantages. First, we don't need to put it through the various preprocessing steps, which saves some cycles and eliminates the need for a number of routines to support PlaceHolderInfo nodes at all. Second, this means one less unused plan for any sub-SELECT appearing in a placeholder's expression, since we don't build placeholder_list until after sublink expansion is complete.
-
- 22 10月, 2008 3 次提交
-
-
由 Teodor Sigaev 提交于
correctly set. As result, killtuple() marks as dead wrong tuple on page. Bug was introduced by me while fixing possible duplicates during GiST index scan.
-
由 Peter Eisentraut 提交于
OFFSET num {ROW|ROWS} FETCH {FIRST|NEXT} [num] {ROW|ROWS} ONLY
-
由 Tom Lane 提交于
that represent some expression that we desire to compute below the top level of the plan, and then let that value "bubble up" as though it were a plain Var (ie, a column value). The immediate application is to allow sub-selects to be flattened even when they are below an outer join and have non-nullable output expressions. Formerly we couldn't flatten because such an expression wouldn't properly go to NULL when evaluated above the outer join. Now, we wrap it in a PlaceHolderVar and arrange for the actual evaluation to occur below the outer join. When the resulting Var bubbles up through the join, it will be set to NULL if necessary, yielding the correct results. This fixes a planner limitation that's existed since 7.1. In future we might want to use this mechanism to re-introduce some form of Hellerstein's "expensive functions" optimization, ie place the evaluation of an expensive function at the most suitable point in the plan tree.
-
- 21 10月, 2008 7 次提交
-
-
由 Peter Eisentraut 提交于
-
由 Peter Eisentraut 提交于
error messages where the type existence is established.
-
由 Peter Eisentraut 提交于
alongside our traditional syntax.
-
由 Alvaro Herrera 提交于
knowledge of page layout. Stolen from Jonah Harris' CRC patch
-
由 Alvaro Herrera 提交于
Zdenek Kotala.
-
由 Alvaro Herrera 提交于
This patch eliminates the marking of subtransactions as SUBCOMMITTED in pg_clog during their commit; instead they remain in-progress until main transaction commit. At main transaction commit, the commit protocol is atomic-by-page instead of one transaction at a time. To avoid a race condition with some subtransactions appearing committed before others in the case where they span more than one pg_clog page, we conserve the logic that marks them subcommitted before marking the parent committed. Simon Riggs with minor help from me
-
- 20 10月, 2008 6 次提交
-
-
由 Peter Eisentraut 提交于
-
由 Peter Eisentraut 提交于
dropped or it was a mistake.
-
由 Peter Eisentraut 提交于
-
由 Teodor Sigaev 提交于
Per Tom's comment. Also revome useless GISTScanOpaque->flags field.
-
由 Peter Eisentraut 提交于
supported, to the extent that LOBs, arrays, and multisets are supported.
-
由 Peter Eisentraut 提交于
-
- 18 10月, 2008 11 次提交
-
-
由 Peter Eisentraut 提交于
-
由 Tom Lane 提交于
-
由 Peter Eisentraut 提交于
-
由 Tom Lane 提交于
(I'm leaving GiST/GIN cleanup to Teodor.)
-
由 Alvaro Herrera 提交于
formatted_start_time.
-
由 Tom Lane 提交于
scanning; GiST and GIN do not, and it seems like too much trouble to make them do so. By teaching ExecSupportsBackwardScan() about this restriction, we ensure that the planner will protect a scroll cursor from the problem by adding a Materialize node. In passing, fix another longstanding bug in the same area: backwards scan of a plan with set-returning functions in the targetlist did not work either, since the TupFromTlist expansion code pays no attention to direction (and has no way to run a SRF backwards anyway). Again the fix is to make ExecSupportsBackwardScan check this restriction. Also adjust the index AM API specification to note that mark/restore support is unnecessary if the AM can't produce ordered output.
-
由 Tom Lane 提交于
set_rel_width(). The code had been catering for the possibility of different varnos in the relation targetlist, but this is impossible for a base relation (and if it were possible, putting all the widths in the same RelOptInfo would be wrong anyway).
-
由 Tom Lane 提交于
-
由 Teodor Sigaev 提交于
several fragments a-la Google. Sushant Sinha <sushant354@gmail.com>
-
由 Teodor Sigaev 提交于
Patch from Sushant Sinha <sushant354@gmail.com> http://archives.postgresql.org/pgsql-hackers/2008-07/msg00785.php
-
由 Teodor Sigaev 提交于
is NULL but SK_SEARCHNULL is not set. Add checking IS NULL of keys to set during key initialization. If key is NULL and SK_SEARCHNULL is not set then nothnig can be satisfied. With assert-enabled compilation that causes coredump. Bug was introduced in 8.3 by support of IS NULL index scan.
-
- 17 10月, 2008 1 次提交
-
-
由 Neil Conway 提交于
In the previous coding, the list of columns that needed to be hashed on was allocated in the per-query context, but we reallocated every time the Agg node was rescanned. Since this information doesn't change over a rescan, just construct the list of columns once during ExecInitAgg().
-