| Commit message (Collapse) | Author | Age |
| |
|
|
|
|
|
| |
code cleanup; no major improvements yet. However, EXPLAIN does produce
more intuitive outputs for nested loops with indexscans now...
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
quote_postgres(...) in ecpglib.c.
The code in CVS reads:
quote_postgres(char *arg, int lineno)
{
char *res = (char *) ecpg_alloc(2 * strlen(arg) + 3, lineno);
int i,
ri = 0;
if (!res)
return (res);
res[ri++] = '\'';
for (i = 0, ri=0; arg[i]; i++, ri++)
{
switch (arg[i])
{
case '\'':
res[ri++] = '\'';
break;
case '\\':
res[ri++] = '\\';
break;
default:
;
}
The problem here is that ri is reset to 0, thus overwriting the initial
quote.
Stephen Birch
|
|
|
|
|
|
|
|
|
| |
if presented an uninitialized (all zeroes) page. The system no longer
crashes hard if an all-zeroes page is present in a relation. There seem
to be some boundary conditions where a page will be appended to a relation
and zeroed, but its page header is never initialized; until we can track
down and fix all of those, robustness seems like a good idea.
Also, clean up some obsolete and downright wrong comments.
|
|
|
|
| |
as well as when inserting entries into an existing index.
|
|
|
|
|
|
|
|
|
| |
still
without answer. I want continue with to_char(), but I need any answer
for this patch. Please.
Thank! (and sorry of my impatient :-)
Karel
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
in trigger manager.
Jan
|
|
|
|
|
|
| |
SET DEFAULT referential action triggers.
Jan
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Update output to new psql conventions.
|
| |
|
| |
|
|
|
|
|
| |
Remove older "::" type coersion syntax in favor of extended SQL92 style.
Include a few new tests for datetime/timespan arithmetic.
|
|
|
|
| |
Include a few new tests for datetime/timespan arithmetic.
|
| |
|
|
|
|
|
| |
rather than the Postgres "::" notation.
All of these tests have been completely inspected and give correct results.
|
|
|
|
| |
All of these tests have been completely inspected and give correct results.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1) datetime_pl_span() added the seconds field before adding the months
field. This lead to erroneous results for e.g.
select datetime '1999-11-30' + timespan '1 mon - 1 sec';
Reverse the order of operations to add months first.
2) tm2timespan() did all intermediate math as integer, converting to double
at the very end. This resulted in hidden overflows when given very large
integer days, hours, etc. For example,
select '74565 days'::timespan;
produced the wrong result. Change code to ensure that doubles are used
for intermediate calculations.
Thanks to Olivier PRENANT <ohp@pyrenet.fr> and
Tulassay Zsolt <zsolt@tek.bke.hu> for problem reports and to Tom Lane for
accurate analyses.
|
| |
|
| |
|
|
|
|
| |
to be Y2K safe.
|
| |
|
|
|
|
|
| |
by continuing to increment the rightmost character until we get a string
that is demonstrably greater than the pattern prefix.
|
|
|
|
|
| |
<= and >= indexquals from a LIKE even if the index in question didn't
support those operators. (As, for example, a hash index does not.)
|
| |
|
|
|
|
| |
sequence doesn't exist.
|
|
|
|
|
|
|
|
|
|
| |
during InitProcessingMode and the CurrentTransactionState was neither
TRANS_DEFAULT nor TRANS_DISABLED. Unfortunately, after someone's recent
change to start the transaction manager earlier in startup than it used
to be started, that caused an abort() and consequent database system
reset on quite harmless errors (such as rejecting an invalid user name!).
As far as I can see, the test on CurrentTransactionState was completely
useless anyway, so I've removed it.
|
| |
|
|
|
|
|
|
| |
relcache entry no longer leaks a small amount of memory. index_endscan
now releases all the memory acquired by index_beginscan, so callers of it
should NOT pfree the scan descriptor anymore.
|
|
|
|
| |
by subselect used as expression."
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Jan
|
| |
|
|
|
|
|
|
|
|
|
| |
This is the patch for the final bit. Sorry that it's separate.
Cheers...
MikeA
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I finally got around to schlepping through pg_dump, to finish what I started
about three months (or more) ago. Attached is a gzipped diff file to apply
in the bin/pg_dump directory. This should remove all string length
dependencies, except one, which I'm working on. It has been through some
rudimentary unit testing, but that's about it, so if any of you would give
it a more strenuous run-through, I'd be grateful for the feedback.
Cheers...
Ansley, Michael
|
| |
|
|
|
|
|
| |
not BLCKSZ/2 as some of us thought. Add check for oversize item so that
failure is detected before corrupting the index, not after.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SELECT null::text;
SELECT int4fac(null);
work as expected now. In some cases a NULL must be surrounded by
parentheses:
SELECT 2 + null; fails
SELECT 2 + (null); OK
This is a grammatical ambiguity that seems difficult to avoid. Other
than that, NULLs seem to behave about like you'd expect. The internal
implementation is that NULL constants are typed as UNKNOWN (like
untyped string constants) until the parser can deduce the right type.
|
| |
|