> The auto-reconnect behavior is long-established and desirable. What's
> not desirable is continuing with any statements remaining on the same
> line, I think. We need to flush the input buffer on reconnect.
So if I understand it correctly, if I need correct transaction behaviour
in psql even
The following bug has been logged online:
Bug reference: 5469
Logged by: Daniele Varrazzo
Email address: daniele.varra...@gmail.com
PostgreSQL version: 8.4
Operating system: any
Description:regexp_matches() has poor behaviour and more poor
documentation
Details:
reg
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
>> The auto-reconnect behavior is long-established and desirable. What's
>> not desirable is continuing with any statements remaining on the same
>> line, I think. We need to flush the input buffer on reconnect.
> So if I understand it correc
Jakub Ouhrabka writes:
> So if I understand it correctly, if I need correct transaction behaviour
> in psql even in case of disconnection the only safe way is to use one
> statement per line.
In existing releases, yes. Having put the BEGIN and UPDATE all on one
line was a necessary preconditio
Hi Jakub,
On 24/05/10 08:52, Jakub Ouhrabka wrote:
> The auto-reconnect behavior is long-established and desirable. What's
> not desirable is continuing with any statements remaining on the same
> line, I think. We need to flush the input buffer on reconnect.
So if I understand it correctly,
The following bug has been logged online:
Bug reference: 5470
Logged by: Randy Solomonson
Email address: pgsqlb...@solomonson.com
PostgreSQL version: 8.4.2
Operating system: Red Hat 4.1.2-46 (64-bit)
Description:EXTRACT(epoch from ...) missing last digit
Details:
Wh
"Randy Solomonson" writes:
> When converting from Timestamp with Time zone to seconds since epoch, the
> last digit of the fraction of a second is missing.
The result of extract() is float8, so you can't really expect it to
have more than about 15 digits of precision.
reg
Today I ran into some interesting consequences of the xml data type
being without an "=" operator. One I thought I'd post here because it
has a *possible* planner impact. I'm not sure it is actually a bug as
such, but this seemed the best forum to post in initially:
test=# \d bug
Table "
While tinkering with some psql settings on 9.0beta1...
[local]:5432|postgres=# \set FETCH_COUNT 1
[local]:5432|postgres=# SELECT foo INTO bar FROM baz;
ERROR: DECLARE CURSOR cannot specify INTO
LINE 2: SELECT foo INTO bar FROM baz;
^
[local]:5432|postgres=#!
If I'm readi
