The following bug has been logged online:
Bug reference: 3403
Logged by: Jasen Betts
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.0
Operating system: window XP (vmware)
Description:ver 8.2 can't add serial column to temp table,but 8.1
can
Details:
gymmas
Jasen Betts wrote:
The following bug has been logged online:
Bug reference: 3403
Logged by: Jasen Betts
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.0
Operating system: window XP (vmware)
Description:ver 8.2 can't add serial column to temp table,but 8.1
c
On Thu, 2007-06-21 at 11:17 +, Katsuhiko Okano wrote:
> Description:PITR does not work in the case of recovery_target_xid =
> 'SELECT_only_transaction_ID'
> Details:
If a transaction is purely read only then there is no COMMIT or ABORT
message written to the transaction log. As a res
Zdenek Kotala wrote:
Jasen Betts wrote:
template1=# create temp table foo ( x text);
CREATE TABLE
template1=# alter table foo add column y text ;
ALTER TABLE
template1=# alter table foo add column id serial;
NOTICE: ALTER TABLE will create implicit sequence "foo_id_seq" for
serial
colum
n "fo
Simon Riggs wrote:
On Thu, 2007-06-21 at 11:17 +, Katsuhiko Okano wrote:
Description:PITR does not work in the case of recovery_target_xid =
'SELECT_only_transaction_ID'
Details:
(snip)
How did you come to choose an xid of this nature?
specify log_statement = 'all' and log_lin
Heikki Linnakangas wrote:
Zdenek Kotala wrote:
Jasen Betts wrote:
template1=# create temp table foo ( x text);
CREATE TABLE
template1=# alter table foo add column y text ;
ALTER TABLE
template1=# alter table foo add column id serial;
NOTICE: ALTER TABLE will create implicit sequence "foo_id_se
This only works as a superuser, but it's wrong nevertheless:
Session 1:
postgres=# CREATE temp table foo (x int);
CREATE TABLE
Session 2:
postgres=# SELECT * FROM pg_temp_1.foo;
x
---
(0 rows)
postgres=# INSERT INTO pg_temp_1.foo values (1);
INSERT 0 1
The insert in session 2 goes to a buffe
Hi,
> As it seems, the result is actually a correct array
It's an array of xid, indeed.
> And comparing the result to for example an int, works.
Only equality only, that is.
> Sidenote: since it does solve my problem, I can now build an index
> based on such an interpretation of xmin
I w
Hi,
While trying to find a way to get indexed access to a table based on it's
xmin, I ran into the following error message that seems a bit misleading:
db=# select xmin || ' ' from limit 1;
ERROR: array value must start with "{" or dimension information
Toying a bit more with this result r
Zdenek Kotala wrote:
I looked on it, but I think let parser to fill namespace information in
ctx->relation structure should be better then do it in this place. There
is also unfilled istemp flag.
Ignore this. It is good place.
However, I think add following function into namespace.c
should b
"Frank van Vugt" <[EMAIL PROTECTED]> writes:
> Sidenote: since it does solve my problem, I can now build an index based on
> such an interpretation of xmin, I'm a bit anxious as to how this will
> be 'fixed', if at all ;)
Actually this was noticed only recently but that was precisely because i
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> This only works as a superuser, but it's wrong nevertheless:
> Session 1:
> postgres=# CREATE temp table foo (x int);
> CREATE TABLE
> Session 2:
> postgres=# INSERT INTO pg_temp_1.foo values (1);
> INSERT 0 1
I can't get excited about preventing
Frank van Vugt <[EMAIL PROTECTED]> writes:
> While trying to find a way to get indexed access to a table based on it's
> xmin, I ran into the following error message that seems a bit misleading:
> db=# select xmin || ' ' from limit 1;
> ERROR: array value must start with "{" or dimension inform
Katsuhiko Okano <[EMAIL PROTECTED]> writes:
> Simon Riggs wrote:
>> How did you come to choose an xid of this nature?
> specify log_statement = 'all' and log_line_prefix = '[%x]' in postgresql.conf
> (I know this approach is not useful and hardly used on actual system
> management.)
No, it's no
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> 8.1 creates the sequence in wrong schema:
Yeah, 8.0 and 8.1 both do the wrong thing really, so it's hard to
argue that this ever worked.
> The problem seems to be in transformColumnDefinition, where the schema
> of the to-be-created sequence is de
The following bug has been logged online:
Bug reference: 3404
Logged by: Maxx
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1
Operating system: Debian GNU/Linux 4.0 (Etch)
Description:Mix ORDER BY ASC With DESC
Details:
When I mix the ORDER BY clause with A
Tom Lane wrote:
This is actually a bit nasty. Your proposed patch doesn't really work,
because of the concern that is now commented at the head of
transformAlterTableStmt:
* CAUTION: resist the temptation to do any work here that depends on the
* current state of the table. Actual execution
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> IOW, we don't actually *know* at parse analysis time which table will be
>> affected.
> I don't understand that. Why would the execution be delayed to a future
> transaction? You can't PREPARE an ALTER TABLE, right?
Yeah, you ca
"Maxx" <[EMAIL PROTECTED]> writes:
> When I mix the ORDER BY clause with ASC and DESC the return is just the
> first field, for example:
You're going to have to provide a complete test case if you want anyone
to take that seriously.
regards, tom lane
-
19 matches
Mail list logo
