| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
relcache entry's reference count is zero.
|
|
Shouldn't create any portability problems, since we have a configure
test to #define away volatile if the compiler doesn't support it.
|
|
|
|
failures. Fix some outright bugs too, including a reference to
uninitialized memory that would cause failures like this one:
select -('1234567890.1234567'::text);
ERROR: Unable to locate type oid 2139062143 in catalog
|
|
This avoids the useless rebuild of pg_version that used to happen on
each build or install pass.
|
|
|
|
|
|
|
|
for Thomas to do the datetime consolidation before touching this, but
it's done now...)
|
|
a specific length or precision, such as foo::char(8). Remove erroneous
removal of user-written casts at the top level of a SELECT target item.
|
|
such as bpchar(char_expression, N), and pull out the attrtypmod that
the function is coercing to. This allows correct deduction of the
column type in examples such as
CREATE VIEW v AS SELECT f1::char(8) FROM tbl;
Formerly we labeled v's column as char-of-unknown-length not char(8).
Also, this change causes the parser not to insert a redundant length
coercion function if the user has explicitly casted an INSERT or UPDATE
expression to the right length.
|
|
fields, nor with bpchar and varchar fields that have typmod -1. The
latter effectively have an unspecified length, so I made them display
as char() and varchar() rather than falsely equating them to char(1)
and varchar(1).
|
|
refer to the single-byte char type. 7.0 was taking it as bpchar(1).
|
|
It worked, because they both have fields named 'data', but it's surely
trouble waiting to happen. I wonder whether there are more ...
|
|
it's a good idea to choose the directory size based on the expected
number of entries. But ShmemInitHash was using a hard-wired constant.
Boo hiss. This accounts for recent report of postmaster failure when
asking for 64K or more buffers.
|
|
|
|
|
|
defaulted the opclass. This addresses TODO item
* Allow creation of functional indexes to use default types
(Does that make it a feature? Oh dear...)
|
|
|
|
from previous release.
|
|
|
|
platform (psql and libpq):
The file "config.h.win32" in the include\ directory (from my patch from
2000-01-18) is missing from the tree. It needs to be put back :-)
The following patch has to be applied in the interfaces\libpq directory.
//Magnus
|
|
thinks the connection is idle, the error message is displayed as if
it were a NOTICE. This seems better than dropping the message on
the floor ... particularly if the message is the backend telling us
why it's about to close the connection. The previous behavior was
Backend message type 0x45 arrived while idle
pqReadData() -- backend closed the channel unexpectedly.
which is not real helpful.
|
|
|
|
|
|
as a unary minus operator for numeric. Now that long numeric constants
will get converted to NUMERIC in early parsing, it's essential to have
numeric->int8 conversion to avoid 'can't convert' errors on undecorated
int8 constants. Threw in the rest for completeness while I was in the
area.
I did not force an initdb for this, since the system will still run
without the new pg_proc/pg_operator entries. Possibly I should've.
|
|
and produce either FLOAT8 or NUMERIC output depending on whether the
value fits in a float8 or not. This is almost back to the way the
code was before I changed T_Float, but there is a critical difference:
now, when a numeric constant doesn't fit in float8, it will be treated
as type NUMERIC instead of type UNKNOWN.
|
|
|
|
|
|
|
|
2. Regression tests fail for types int2 and int4 (which can easily be
fixed by adding entries to resultmap) aswell as float8 and geometry,
where floating point numbers appear to be rounded a little differently
than in your expected results (besides that I also need the positive
zeros file). I'm including a patch for the first 2, but I don't know
whether the latter two are actually a bug in postgres or a bug in the
OS or even allowed difference. I'm including my results for reference.
Rolf Grossmann
|
|
tests for the Foreign Key support in 7.0 which
was made against a CVS copy from this
afternoon.
This modifies
src/test/regress/sql/run_check.tests
src/test/regress/sql/alter_table.sql
src/test/regress/expected/alter_table.out
src/test/regress/sql/foreign_key.sql
src/test/regress/expected/foreign_key.out
sszabo@bigpanda.co
|
|
|
|
|
|
failed to negate a negative value back to positive, so '- - 123.45'
did the wrong thing.
|
|
Thomas gets back, but better this than nonfunctional pg_dump in the beta.
|
|
|
|
|
|
integers) to be strings instead of 'double'. We convert from string form
to internal representation only after type resolution has determined the
correct type for the constant. This eliminates loss-of-precision worries
and gets rid of the change in behavior seen at 17 digits with the
previous kluge.
|
|
test output as expected output. We'll probably want to change this again
after something's done about the verbosity of column alias display.
|
|
|
|
Jan
|
|
|
|
performance in catcache lookups.
|
