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
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 "
"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
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
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,
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
-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
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
> 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
