- 19 2月, 2007 6 次提交
-
-
由 Magnus Hagander 提交于
binary dump formats.
-
由 Magnus Hagander 提交于
-
由 Tom Lane 提交于
this code was last gone over, there wasn't really any alternative to globals because we didn't have the PlannerInfo struct being passed all through the planner code. Now that we do, we can restructure things to avoid non-reentrancy. I'm fooling with this because otherwise I'd have had to add another global variable for the planned compact range table list.
-
由 Tom Lane 提交于
Per example from Jeff Ross.
-
由 Tom Lane 提交于
plan nodes, so that the executor does not need to get these items from the range table at runtime. This will avoid needing to include these fields in the compact range table I'm expecting to make the executor use.
-
由 Tom Lane 提交于
portals using PORTAL_UTIL_SELECT strategy. This is currently significant only for FETCH queries, which are supposed to include a count in the tag. Seems it's been broken since 7.4, but nobody noticed before Knut Lehre.
-
- 18 2月, 2007 5 次提交
-
-
由 Bruce Momjian 提交于
string.
-
由 Bruce Momjian 提交于
< Currently, ALTER USER and ALTER DATABASE support per-user and > Currently ALTER USER and ALTER DATABASE support per-user and < Currently, subtracting one date from another that crosses a > Currently subtracting one date from another that crosses a < Currently, SQL-language functions can only refer to parameters via $1, etc > Currently SQL-language functions can only refer to dollar parameters, > e.g. $1 < Currently, queries prepared via the libpq API are planned on first > Currently queries prepared via the libpq API are planned on first < Currently, SET <tab> causes a database lookup to check all > Currently SET <tab> causes a database lookup to check all < Currently, all statement results are transferred to the libpq > Currently all statement results are transferred to the libpq
-
由 Bruce Momjian 提交于
* Allow SQL-language functions to reference parameters by parameter name Currently SQL-language functions can only refer to parameters via $1, etc
-
由 Bruce Momjian 提交于
current/requested headings, add link to table from text.
-
由 Tom Lane 提交于
equal functions are checked for raw parse trees as well as post-analysis trees. This was never very important before, but the upcoming plan cache control module will need to be able to do copyObject() on raw parse trees.
-
- 17 2月, 2007 15 次提交
-
-
由 Bruce Momjian 提交于
we can't overflow to the next higher units, and we might print the lower units for MS.
-
由 Bruce Momjian 提交于
> * Allow holdable cursors in SPI
-
由 Bruce Momjian 提交于
Brendan Jurd
-
由 Bruce Momjian 提交于
> > o Allow row and record variables to be set to NULL constants, > and allow NULL tests on such variables > > Because a row is not scalar, do not allow assignment > from NULL-valued scalars.
-
由 Bruce Momjian 提交于
floating point.
-
由 Bruce Momjian 提交于
as a performance enhancement. Mark Kirkwood
-
由 Tom Lane 提交于
forces a particular relation nonnullable, then we can say that the OR does. This is worth a little extra trouble since it may allow reduction of outer joins to plain joins.
-
由 Bruce Momjian 提交于
> o Consider reducing on-disk varlena length from four to two > because a heap row cannot be more than 64k in length
-
由 Tom Lane 提交于
an opclass for a generic type such as ANYARRAY. The original coding failed to check that PK and FK columns were of the same array type. Per discussion with Tom Dunstan. Also, make the code a shade more readable by not trying to economize on variables.
-
由 Bruce Momjian 提交于
on platforms that need this. This is done by only writing past the previously stored message, if it was longer.
-
由 Tom Lane 提交于
JOIN quals, just like WHERE quals, even if they reference every one of the join's relations. Now that we can reorder outer and inner joins, it's possible for such a qual to end up being assigned to an outer join plan node, and we mustn't have it treated as a join qual rather than a filter qual for the node. (If it were, the join could produce null-extended rows that it shouldn't.) Per bug report from Pelle Johansson.
-
由 Peter Eisentraut 提交于
require stdint.h and works for "busted" int64.
-
由 Alvaro Herrera 提交于
remove duplicated tests in timestamp, and complete timestamptz with the tests that were missing to more closely mirror timestamp.
-
由 Tom Lane 提交于
-
由 Tom Lane 提交于
-
- 16 2月, 2007 12 次提交
-
-
由 Alvaro Herrera 提交于
timestamp_tbl table into the timestamp test. Also, restore a test that used to exist as a valid test in the timestamptz test.
-
由 Peter Eisentraut 提交于
-
由 Peter Eisentraut 提交于
-
由 Peter Eisentraut 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
detection of tabs are added in the future.
-
由 Tom Lane 提交于
be checked at plan levels below the top; namely, we have to allow for Result nodes inserted just above a nestloop inner indexscan. Should think about using the general Param mechanism to pass down outer-relation variables, but for the moment we need a back-patchable solution. Per report from Phil Frost.
-
由 Bruce Momjian 提交于
to_timestamp(): - ID for day-of-week - IDDD for day-of-year This makes it possible to convert ISO week dates to and from text fully represented in either week ('IYYY-IW-ID') or day-of-year ('IYYY-IDDD') format. I have also added an 'isoyear' field for use with extract / date_part. Brendan Jurd
-
由 Bruce Momjian 提交于
o read global SSL configuration file o add GUC "ssl_ciphers" to control allowed ciphers o add libpq environment variable PGSSLKEY to control SSL hardware keys Victor B. Wagner
-
由 Alvaro Herrera 提交于
startup and bgwriter processes), and the -y flag. It's not used anywhere.
-
由 Tom Lane 提交于
considered when it is necessary to do so because of a join-order restriction (that is, an outer-join or IN-subselect construct). The former coding was a bit ad-hoc and inconsistent, and it missed some cases, as exposed by Mario Weilguni's recent bug report. His specific problem was that an IN could be turned into a "clauseless" join due to constant-propagation removing the IN's joinclause, and if the IN's subselect involved more than one relation and there was more than one such IN linking to the same upper relation, then the only valid join orders involve "bushy" plans but we would fail to consider the specific paths needed to get there. (See the example case added to the join regression test.) On examining the code I wonder if there weren't some other problem cases too; in particular it seems that GEQO was defending against a different set of corner cases than the main planner was. There was also an efficiency problem, in that when we did realize we needed a clauseless join because of an IN, we'd consider clauseless joins against every other relation whether this was sensible or not. It seems a better design is to use the outer-join and in-clause lists as a backup heuristic, just as the rule of joining only where there are joinclauses is a heuristic: we'll join two relations if they have a usable joinclause *or* this might be necessary to satisfy an outer-join or IN-clause join order restriction. I refactored the code to have just one place considering this instead of three, and made sure that it covered all the cases that any of them had been considering. Backpatch as far as 8.1 (which has only the IN-clause form of the disease). By rights 8.0 and 7.4 should have the bug too, but they accidentally fail to fail, because the joininfo structure used in those releases preserves some memory of there having once been a joinclause between the inner and outer sides of an IN, and so it leads the code in the right direction anyway. I'll be conservative and not touch them.
-
由 Alvaro Herrera 提交于
continuously, and requests vacuum runs of "autovacuum workers" to postmaster. The workers do the actual vacuum work. This allows for future improvements, like allowing multiple autovacuum jobs running in parallel. For now, the code keeps the original behavior of having a single autovac process at any time by sleeping until the previous worker has finished.
-
- 15 2月, 2007 2 次提交
-
-
由 Tom Lane 提交于
platform-specific result ordering. Per buildfarm results.
-
由 Tom Lane 提交于
WHERE clauses. createplan.c is now willing to stick a gating Result node almost anywhere in the plan tree, and in particular one can wind up directly underneath a MergeJoin node. This means it had better be willing to handle Mark/Restore. Fortunately, that's trivial in such cases, since we can just pass off the call to the input node (which the planner has previously ensured can handle Mark/Restore). Per report from Phil Frost.
-