| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
| |
be an expression not just a simple Var, so long as only one table is
referenced (so that code isn't really any more difficult than before).
This whole thing is still fundamentally bogus, but at least we can accept
a few more cases than before.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
WHERE in a place where it can be part of a nestloop inner indexqual.
As the code stood, it put the same physical sub-Plan node into both
indxqual and indxqualorig of the IndexScan plan node. That confused
later processing in the optimizer (which expected that tracing the
subPlan list would visit each subplan node exactly once), and would
probably have blown up in the executor if the planner hadn't choked first.
Fix by making the 'fixed' indexqual be a complete deep copy of the
original indexqual, rather than trying to share nodes below the topmost
operator node. This had further ramifications though, because we were
making the aforesaid list of sub-Plan nodes during SS_process_sublinks
which is run before construction of the 'fixed' indexqual, meaning that
the copy of the sub-Plan didn't show up in that list. Fix by rearranging
logic so that the sub-Plan list is built by the final set_plan_references
pass, not in SS_process_sublinks. This may sound like a mess, but it's
actually a good deal cleaner now than it was before, because we are no
longer dependent on the assumption that planning will never make a copy
of a sub-Plan node.
|
|
|
|
|
|
|
|
|
|
| |
pg_internal.init file in-place, which meant that if another backend
started at about the same time, it might read the incomplete file.
init_irels tries to guard against that, but I have now seen a crash
due to reading bad data from a partly-written file. (This may indicate
a kernel bug on my platform? Not sure.) Anyway, clearly the safest
course is to write the new pg_internal.init file under a unique temporary
filename, and rename it into place only after it's all written.
|
|
|
|
|
|
|
|
| |
In the event of an elog() while the mode was set to immediate write,
there was no way for it to be set back to the normal delayed write.
The mechanism was a waste of space and cycles anyway, since the only user
was varsup.c, which could perfectly well call FlushBuffer directly.
Now it does just that, and the notion of a write mode is gone.
|
|
|
|
| |
from gcc. Which wasn't actually a code bug, but I don't like warnings.
|
|
|
|
|
|
| |
single integers, and lists of names, without surrounding them with quotes.
Remove all tokens which are defined as operators from ColID and ColLabel
to avoid precedence confusion. Thanks to Tom Lane for catching this.
|
|
|
|
|
|
|
| |
to next integer. Previously, if selectivity was small, we could compute
very tiny scan cost on the basis of estimating that only 0.001 tuple
would be fetched, which is silly. This naturally led to some rather
silly plans...
|
|
|
|
| |
years. Rejects dates like '0.085', which were accepted previously.
|
|
|
|
|
|
|
| |
Move CREATE FUNCTION/WITH clause to end of statement to get around
shift/reduce conflicts with type names containing "WITH".
Add lots of tokens as allowed ColId's and/or ColLabel's,
so this should be a complete set for the v7.0 release.
|
|
|
|
|
| |
and only one transition state, but the CREATE AGGREGATE code rejected
this combination.
|
|
|
|
| |
Fixed bug in createdb/alternative location
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
keys lists of Constraint nodes. This eliminates a type pun that would
probably have caused trouble someday, and eliminates circular references
in the parsetree that were causing trouble now.
Also, change parser's uses of strcasecmp() to strcmp(). Since scan.l
has downcased any unquoted identifier, it is never correct to check an
identifier with strcasecmp() in the parser. For example,
CREATE TABLE FOO (f1 int, UNIQUE("F1"));
was accepted, which is wrong, and xlateSqlFunc did more than it should:
select datetime();
ERROR: Function 'timestamp()' does not exist
(good)
select "DateTime"();
ERROR: Function 'timestamp()' does not exist
(bad)
|
|
|
|
| |
is no presorted path to compare with.
|
|
|
|
| |
to trouble when trying to EXPLAIN VERBOSE a plan containing one.
|
|
|
|
|
|
| |
Clean up grotty coding in them, too. AFAICS from the CVS logs, these
have been broken since Postgres95, so I'm not going to insist on an
initdb to fix them now...
|
|
|
|
|
|
|
| |
to avoid undue sensitivity to roundoff error, believe that a zero
or slightly negative range estimate should represent a small
positive selectivity, rather than falling back on a generic default
estimate.
|
|
|
|
|
|
| |
easy (maybe dumb) fix for 5 in attachment define.patch
greetings, Andreas
|
|
|
|
|
|
|
| |
patch in a second. Should be sufficent to just make sure the first
character is a '/', right?
Ross J. Reedstrom
|
|
|
|
| |
input, not throw a gratuitous elog().
|
|
|
|
|
| |
outside WHERE clause. Fix a couple of places that didn't handle uplevel
refs cleanly.
|
|
|
|
|
| |
nodes introduced by make_subplan(). It'd be better if we used a
different node type for subplan result placeholders, but for now...
|
|
|
|
| |
Const placeholder nodes for subplan result values.
|
|
|
|
|
|
| |
use a default value that's fairly small. We were generating a result
of about 0.1, but I think 0.01 is probably better --- want to encourage
use of an indexscan in this situation.
|
|
|
|
|
| |
to more than one character, and try to do the right thing in non-ASCII
locales.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
costs using the inner path's parent->rows count as the number of tuples
processed per inner scan iteration. This is wrong when we are using an
inner indexscan with indexquals based on join clauses, because the rows
count in a Relation node reflects the selectivity of the restriction
clauses for that rel only. Upshot was that if join clause was very
selective, we'd drastically overestimate the true cost of the join.
Fix is to calculate correct output-rows estimate for an inner indexscan
when the IndexPath node is created and save it in the path node.
Change of path node doesn't require initdb, since path nodes don't
appear in saved rules.
|
|
|
|
|
|
| |
is available yet.
Remove redundant call to xlateSqlType() in the character
type handling code.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to simplify constant expressions and expand SubLink nodes into SubPlans
is done in a separate routine subquery_planner() that calls union_planner().
We formerly did most of this work in query_planner(), but that's the
wrong place because it may never see the real targetlist. Splitting
union_planner into two routines also allows us to avoid redundant work
when union_planner is invoked recursively for UNION and inheritance
cases. Upshot is that it is now possible to do something like
select float8(count(*)) / (select count(*) from int4_tbl) from int4_tbl
group by f1;
which has never worked before.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
incorrect use of StrNCpy.
|
|
|
|
| |
leading to postmaster accepting args 1 shorter than it had room for.
|
| |
|
|
|
|
|
|
|
|
|
| |
had already been transformed. This led to failure in examples like
UPDATE table SET fld = (SELECT ...). Repair this, and revise the
comments to explain that transformExpr has to be robust against this
condition. Someday we might want to fix the callers so that
transformExpr is never invoked on its own output, but that someday
is not today.
|
|
|
|
|
|
|
|
|
|
| |
In function parsing, try for an actual function of the given name and
input types before trying to interpret the function call as a type
coercion request, rather than after. Before, a function that had the
same name as a type and operated on a binary-compatible type wouldn't
get invoked. Also, cross-pollinate between func_select_candidates and
oper_select_candidates to ensure that they use as nearly the same
resolution rules as possible. A few other minor code cleanups too.
|
|
|
|
| |
actually returns the type it is named for.
|
|
|
|
|
|
| |
problem could be lack of parentheses. This addresses cases like
X UserOp UserOp Y, which will be parsed as (X UserOp) UserOp Y,
whereas what likely was wanted was X UserOp (UserOp Y).
|
| |
|
|
|
|
|
|
|
|
|
|
| |
16-Mar-00: trailing + or - is not part of the operator unless the operator
also contains characters not present in SQL92-defined operators. This
solves the 'X=-Y' problem without unduly constraining users' choice of
operator names --- in particular, no existing Postgres operator names
become invalid.
Also, remove processing of // comments, as agreed in the same thread.
|
|
|
|
|
| |
prefix operator :-(. Bad enough that we have no implementation of
unary plus, but at least with this fix the grammar will take it.
|
| |
|
|
|
|
| |
a config.h #define, and the runtime value can be controlled via SET.
|
|
|
|
|
|
| |
running gcc and HP's cc with warnings cranked way up. Signed vs unsigned
comparisons, routines declared static and then defined not-static,
that kind of thing. Tedious, but perhaps useful...
|
|
|
|
|
|
| |
We probably support a superset of the spec, but I don't have the spec
to confirm this.
Update regression tests to include tests for this format.
|
|
|
|
|
|
| |
actually a type-coercion problem. If you have a function defined on
class A, and class B inherits from A, then the function ought to work
on class B as well --- but coerce_type didn't know that. Now it does.
|
|
|
|
|
|
|
| |
mark query as having subselects if a subselect was added from a rule
WHERE condition (as opposed to a rule action). Also, fix adjustment
of varlevelsup so that it actually has some prospect of working when
inserting an expression containing a subselect into a subquery.
|