| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
the case wherein zero was rejected for a field like NUMERIC(4,4).
Miscellaneous other code beautification efforts.
|
| |
|
|
|
|
|
| |
functions, which would lead to trouble with datatypes that paid attention
to the typelem or typmod parameters to these functions. In particular,
incorrect code in pg_aggregate.c explains the platform-specific failures
that have been reported in NUMERIC avg().
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
* Let unprivileged users change their own passwords.
* The password is now an Sconst in the parser, which better reflects its text datatype and also
forces users to quote them.
* If your password is NULL you won't be written to the password file, meaning you can't connect
until you have a password set up (if you use password authentication).
* When you drop a user that owns a database you get an error. The database is not gone.
|
| |
|
|
| |
error-proof. Rearranged some old code and removed dead sections.
|
| |
|
|
|
| |
Update README so that it reflects all source file names
Add an entry to make sjistest (testing between SJIS/EUC_JP conversion)
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
properly.
|
| |
|
|
|
|
| |
this would fix TODO
* elog() flushes cache, try invalidating just entries from
current xact, perhaps using invalidation cache
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
postmaster/postmaster.c so that
tcop/postgres.c can use them. Now we have an interlock between
postmaster and postgres.
|
| |
|
|
|
| |
code cleanup; no major improvements yet. However, EXPLAIN does produce
more intuitive outputs for nested loops with indexscans now...
|
| |
|
|
|
|
|
|
|
| |
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
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
Jan
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
during backend startup.
|
| |
|
|
|
|
|
|
|
|
|
| |
with DEC C.
DEC C doesn't handle double values greater than DBL_MAX, but some
PostgreSQL geo functions assign greater than DBL_MAX values to some vars
in some special cases - that couses SIGFPE. I dunno if that is the only place
to fix to work well with DEC C.
Kirill Nosov.
|
| |
|
|
|
|
|
| |
rather than returning a NaN for bogus input to pow(). Namely, HPUX 10.20.
I think this is sufficient evidence for what I thought all along, which
is that the float.c code *must* look at errno whether finite() exists or
not.
|
| | |
|
| |
|
|
| |
Jan
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
equality. The lobits macro is wrong and extracts the wrong set of
bits out of the structure.
To exhibit the problem:
select '000000:000000'::macaddr = '000000:110000'::macaddr ;
?column?
--------
t
(1 row)
Daniel Boyd
|
| | |
|
| |
|
|
| |
Note this forces initdb because of change of Aggref node in stored rules.
|
| |
|
|
|
|
| |
time qualification of HeapTupleSatisfiesSnapshot()
Jan
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I was able to crash postgres 6.5.3 when I did an 'alter user' command.
After I started a debugger I found the problem in the timezone handling
of
datetime (my Linux box lost its timezone information, that's how the
problem occurred).
Only 7 bytes are reserved for the timezone, without checking for
boundaries.
Attached is a patch that fixes this problem and emits a NOTICE if a
timezone is encountered that is longer than MAXTZLEN bytes, like this:
Jeroen van Vianen
|
| |
|
|
| |
Jan
|
| |
|
|
| |
Jan
|
| |
|
|
| |
Jan
|
