| Age | Commit message (Collapse) | Author |
|---|
|
Now SET NAMES working again...
|
|
Also, improve it so that it checks for multi-column constraints.
Thanks to Mark Dalphin <mdalphin@amgen.com> for reporting the problem.
|
|
a SubLink with the subplan's targetlist. This fixes a problem seen with,
for example, a subselect that uses GROUP BY.
|
|
|
|
|
|
|
|
|
|
SubLink nodes after all ...
|
|
is parse_aggs.c. This fixes its failure to cope with (at least) CaseExpr
and ArrayRef nodes, which is the reason why both of these fail in 6.5:
select coalesce(f1,0) from int4_tbl group by f1;
ERROR: Illegal use of aggregates or non-group column in target list
select sentence.words[0] from sentence group by sentence.words[0];
ERROR: Illegal use of aggregates or non-group column in target list
The array case still fails, but at least it's not parse_agg's fault
anymore ... considering that we now support CASE officially, I think
it's important to fix the first example ...
|
|
used to overrun its fixed-size arrays before detecting error; not cool).
Also, replace uses of magic constant '8' with 'MAXFARGS'.
|
|
a non-leading % would be put into the >=/<= patterns. Also, repair
longstanding confusion about whether %% means a literal %%. The SQL92
doesn't say any such thing, and textlike() knows that, but gram.y didn't.
|
|
index, etc is too long, truncate until it fits.
|
|
few percent speedup in INSERT...
|
|
|
|
|
|
|
|
GROUP BY or ORDER BY expressions in INSERT ... SELECT.
|
|
aggregate functions, as in
select a, b from foo group by a;
The ungrouped reference to b is not kosher, but formerly we neglected to
check this unless there was an aggregate function somewhere in the query.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
SelectStmt and CursorStmt tried to parse FOR UPDATE ... / FOR READ ONLY.
Cursor now checks that it is read only by looking at forUpdate of Query.
SelectStmt handles FOR READ ONLY too.
Jan
|
|
|
|
|
|
will pass through rather than spitting up. This is necessary to handle
cases where coerce_type causes a subexpression to be retransformed, as in
SELECT count(*) + 1.0 FROM table
|
|
|
|
|
|
for SERIAL column's constraint, but forgot to increase space palloc'd...
|
|
|
|
|
|
|
|
|
|
SERIAL data type DEFAULT clause.
This fixes a problem finding the sequence name when mixed case table names
are involved.
|
|
compiler warnings about an unused variable.
|
|
lists are now plain old garden-variety Lists, allocated with palloc,
rather than specialized expansible-array data allocated with malloc.
This substantially simplifies their handling and eliminates several
sources of memory leakage.
Several basic types of erroneous queries (syntax error, attempt to
insert a duplicate key into a unique index) now demonstrably leak
zero bytes per query.
|
|
in Resdom and GroupClause so changing of resno's doesn't confuse
the grouping any more.
Jan
|
|
and lock syntax as fully parsed tokens.
Two keywords for isolation are non-reserved SQL92
(COMMITTED, SERIALIZABLE).
All other new keywords are non-reserved Postgres (not SQL92)
(ACCESS, EXCLUSIVE, MODE, SHARE).
Add syntax to allow CREATE [GLOBAL|LOCAL] TEMPORARY TABLE, throwing an
error if GLOBAL is specified.
|
|
constraints. Reported by Tom Lane.
Now, check for duplicate indices and retain the one which is a primary-key.
Adjust elog NOTICE messages to surround table and column names with single
quotes.
|
|
|
|
the obvious conversion.
Define a new pattern "decimal" which is non-exponential floating point
for use with numeric() and decimal() types.
|
|
|
|
real affect now.
|
|
been applied. The patches are in the .tar.gz attachment at the end:
varchar-array.patch this patch adds support for arrays of bpchar() and
varchar(), which where always missing from postgres.
These datatypes can be used to replace the _char4,
_char8, etc., which were dropped some time ago.
block-size.patch this patch fixes many errors in the parser and other
program which happen with very large query statements
(> 8K) when using a page size larger than 8192.
This patch is needed if you want to submit queries
larger than 8K. Postgres supports tuples up to 32K
but you can't insert them because you can't submit
queries larger than 8K. My patch fixes this problem.
The patch also replaces all the occurrences of `8192'
and `1<<13' in the sources with the proper constants
defined in include files. You should now never find
8192 hardwired in C code, just to make code clearer.
--
Massimo Dal Zotto
|
|
that, but it'd be a New Feature, wouldn't it ... in the meantime,
avoiding a backend crash seems worthwhile.
|
|
Things are better now.
|
|
Jan
|
|
|
