Ryan Kelly writes:
> It seems that ALTER TABLE ... OWNER TO does not change the ownership of
> any inheriting tables. The documentation states:
>> If ONLY is specified, only that table is altered. If ONLY is not
>> specified, the table and any descendant tables are altered.
If you read further (
It seems that ALTER TABLE ... OWNER TO does not change the ownership of
any inheriting tables. The documentation states:
> If ONLY is specified, only that table is altered. If ONLY is not
> specified, the table and any descendant tables are altered.
Which to me indicates that ownership should be
"Alex Hunsaker" writes:
> Namely it does not disable the rule... Enabling inside of the
> transaction seems to work though
Fixed, thanks ...
Index: relcache.c
===
RCS file: /cvsroot/pgsql/src/backend/utils/cache/relcache.c,v
retriev
On Mon, Dec 29, 2008 at 15:07, Alex Hunsaker wrote:
> Namely it does not disable the rule...
> Enabling inside of the transaction seems to work though
Hrm the above turned out to be false... must have gotten confused when
testing with triggers
If i turn on RELCACHE_FORCE_RELEASE or CLOBBER_CACH
Namely it does not disable the rule... Enabling inside of the
transaction seems to work though
Tried both CVS and 8.3.5...
create table trule (a int);
insert into trule (a) values (1);
create rule trule_rule as on update to trule do instead nothing;
update trule set a = 2;
UPDATE 0
begin;
ALTER
On 9 Srp, 19:38, [EMAIL PROTECTED] (Gregory Stark) wrote:
> <[EMAIL PROTECTED]> writes:
> > ALTER TABLE name RENAME TO new_name;
> > ALTER TABLE new_name
> > RENAME COLUMN x TO y;
>
> ...
> > I think the issue might be reproducible by creating table with a lot
> > of rows, setting high work_mem a
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Apparently, rd_indexattr needs to get cleared someplace where it
> isn't being cleared right now. I'm sure this is related to the
> fancy dance we do for pg_class reindexing, but not sure yet where
> to fix it.
Yeah, doing the equivalent of this in gdb se
Gregory Stark <[EMAIL PROTECTED]> writes:
> Uhm. Is it possible we're mistakenly doing a HOT update because we're lying
> about what indexes exist?
Yup, exactly. Here's my proposed fix...
regards, tom lane
Index: src/backend/catalog/index.c
==
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Also, I can still reproduce it with just REINDEX TABLE pg_class instead
> of REINDEX DATABASE.
Ah, I had tried just a reindex xxx but not a reindex pg_class.
* reindex_index will attempt to update the pg_class rows for the
relation
* an
I wrote:
> What I suspect is we've broken the logic that manages REINDEX applied to
> pg_class itself.
Hm, this is a HOT bug. (Unless the OP found it on something older
than 8.3, in which case we might have more than one issue involved.)
What I'm seeing is that when heap_update checks to see if t
Gregory Stark <[EMAIL PROTECTED]> writes:
> On the other hand the problem does not occur if the CREATE TABLE is in the
> same session. Nor if the REINDEX DATABASE is skipped.
It appears that you have to do the RENAME TABLE in the same session as
the REINDEX DATABASE. Furthermore, the failure then
"Alvaro Herrera" <[EMAIL PROTECTED]> writes:
>> > I could not reproduce it here, but didn't try very hard.
>>
>> Did you try running the script he provided? It happened for me first try.
>
> Yep. No luck. I didn't try changing the args in generate_series though.
>
> How many CPUs are you runnin
Gregory Stark escribió:
> Either a) we're not actually issuing a CommandCounterIncrement() or b) the
> command is not being properly marked as non-read-only when the update happens
> or, uh, c) something else is broken with generating or executing those
> invalidation messages.
Well, the CommandC
"Alvaro Herrera" <[EMAIL PROTECTED]> writes:
> Gregory Stark escribió:
>>
>> <[EMAIL PROTECTED]> writes:
>>
>> > Here is a script that is able to reproduce the problem (on my machine
>> > anyway), you may need to play with the number of rows or workmem
>> > settings to be able to reproduce it:
>
Gregory Stark escribió:
>
> <[EMAIL PROTECTED]> writes:
>
> > Here is a script that is able to reproduce the problem (on my machine
> > anyway), you may need to play with the number of rows or workmem
> > settings to be able to reproduce it:
>
> Egads, i can confirm that this script reproduces t
<[EMAIL PROTECTED]> writes:
> Here is a script that is able to reproduce the problem (on my machine
> anyway), you may need to play with the number of rows or workmem
> settings to be able to reproduce it:
Egads, i can confirm that this script reproduces the problem on my machine as
well:
ALTER
Here is a script that is able to reproduce the problem (on my machine
anyway), you may need to play with the number of rows or workmem
settings to be able to reproduce it:
regards,
Ondrej Jirman
#!/bin/sh
dropdb bug
createdb bug
psql bug << EOF
CREATE TABLE xxx (id SERIAL, col1 TEXT, col2
<[EMAIL PROTECTED]> writes:
> ALTER TABLE name RENAME TO new_name;
> ALTER TABLE new_name
> RENAME COLUMN x TO y;
>
...
> I think the issue might be reproducible by creating table with a lot
> of rows, setting high work_mem and issuing the commands, but I did not
> try to reproduce it this way.
Oh, I've forgot to mention that the commands are issued from the
script. When issued by hand there is no problem at all (probably
because I'm a slow typist :-D).
Thank you and regards,
Ondrej Jirman
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subs
Hello,
I don't know if this is expected behaviour or not, but I've found that
this sequence of commands does not work all the time:
ALTER TABLE name RENAME TO new_name;
ALTER TABLE new_name
RENAME COLUMN x TO y;
It usually works with small work_mem and maintenance_work_mem values.
If I increas
"Donald Fraser" <[EMAIL PROTECTED]> writes:
> When issuing the following type of command:
> ALTER TABLE table RENAME COLUMN x TO y
> The column name change is not cascading through to RULEs on a VIEW.
More specifically, INSERTs and UPDATEs contained in rules don't have
their target column names ad
Postgresql 7.3.4 on Linux.
Problem is that when you create a table with serial type, it creates
sequence with coresponding name. Then you can grant some rights to
it (table and sequence), and after that change table name. From now on
you will not be able to restore such database, because name of s
PostgreSQL version 7.3.3, GCC 2.96, Redhat 7.2
When issuing the following type of command:
ALTER TABLE table RENAME COLUMN x TO y
The column name change is not cascading through to RULEs on a VIEW.
For example I had a column named "id_security" in TABLE "tbl_valrule" and I had
a RULE on a view th
TODO has:
o Have ALTER TABLE rename SERIAL sequences
However, I didn't realize the seriousness of the problem.
---
Mirek Hankus wrote:
>
> Postgresql 7.3.4 on Linux.
>
> Problem is that when you create a table wi
Tom Lane wrote:
> "Donald Fraser" <[EMAIL PROTECTED]> writes:
> > When issuing the following type of command:
> > ALTER TABLE table RENAME COLUMN x TO y
> > The column name change is not cascading through to RULEs on a VIEW.
>
> More specifically, INSERTs and UPDATEs contained in rules don't have
"Diego Cattelan" <[EMAIL PROTECTED]> writes:
> gesart=3D>alter table a add column c integer references xxx(id);
> =20
> NOTICE: ALTER TABLE will create implicit trigger(s) for FOREIGN KEY check(s)
> ALTER TABLE
> =20
> The table xxx doesn't exist.
> =20
> Is that correct or postgreSQL shoul
Title: Messaggio
template1=#create database
gesart;
template1=#create user
xuser;
template1=# \c gesart xuser
gesart=>create
table a(n integer);
CREATE
TABLE
gesart=>alter table a add column c integer
references xxx(id);
NOTICE: ALTER TABLE
will create implicit trigger(s) for FOR
Hi,
- I tried to execute following SQL alter table PRICEGROUP add FOREIGN KEY ("PARENT") REFERENCES "PRICEGROUP" ON DELETE CASCADE
this gives an error ALTER TABLE: column "PARENT" referenced in foreign key constraint does not exist (7) while I'm sure that the column exists and is Non null. I'm
Vince Vielhaber <[EMAIL PROTECTED]> writes:
> If this:
> alter table foobar add column address varchar(50) default 'none';
> is the incorrect syntax, why does it not fail or at least give a
> warning?
Because it's incompletely implemented: the parser takes the full syntax
but the ALTER TABLE rout
On 8 May 2001, Nabil Sayegh wrote:
> On 05 May 2001 12:23:37 -0400, [EMAIL PROTECTED] wrote:
> > Vince Vielhaber ([EMAIL PROTECTED]) reports a bug with a severity of 3
> > The lower the number the more severe it is.
> >
> > Short Description
> > Alter table add column ignores default
> >
> > Long
On 8 May 2001, Nabil Sayegh wrote:
> On 08 May 2001 10:31:17 -0400, Vince Vielhaber wrote:
> > > http://hermes.swu.bg/postgres/postgres/sql-altertable.htm
> > > The correct syntax is:
> > > ALTER TABLE foobar add column address varchar(50);
> > > ALTER TABLE foobar alter column address set defaul
On 08 May 2001 10:31:17 -0400, Vince Vielhaber wrote:
> > http://hermes.swu.bg/postgres/postgres/sql-altertable.htm
> > The correct syntax is:
> > ALTER TABLE foobar add column address varchar(50);
> > ALTER TABLE foobar alter column address set default 'none';
>
> If this:
>
> alter table fooba
On 05 May 2001 12:23:37 -0400, [EMAIL PROTECTED] wrote:
> Vince Vielhaber ([EMAIL PROTECTED]) reports a bug with a severity of 3
> The lower the number the more severe it is.
>
> Short Description
> Alter table add column ignores default
>
> Long Description
> Alter table add column ignores the
Vince Vielhaber ([EMAIL PROTECTED]) reports a bug with a severity of 3
The lower the number the more severe it is.
Short Description
Alter table add column ignores default
Long Description
Alter table add column ignores the default values in both v7.0x and 7.1. In the
example code the table is
Hi,
I've discovered a bug in Postgres. When you rename
a table, the corresponding triggers for that table
are not updated.
For example:
CREATE TABLE tblParent (
ID SERIAL NOT NULL,
Name text,
PRIMARY KEY (ID)
);
CREATE TABLE tblChild (
ID int4 NOT NULL,
email text,
FOREIGN KEY
> It appears that the triggers were never updated to now refer to 'old'
> instead of to current_usage when it was renamed, but were still
> associated with 'old' for purposes of dropping them. (i presume this
> is because the triggers were attached to 'old' by oid, which didnt
> change when it wa
Dave E Martin ([EMAIL PROTECTED]) reports a bug with a severity of 3
The lower the number the more severe it is.
Short Description
alter table rename and ruminations on referential integrity
Long Description
PostgreSQL 7.0.3 on i686-pc-linux-gnu, compiled by gcc 2.95.2
I suspect symptoms of thi
> template1=> insert into n2 values(154.23);
> INSERT 360703 1
> template1=> alter table n1 rename to oldn1;
> RENAME
> template1=> alter table n2 rename to n1;
> RENAME
> template1=> insert into n1 values(154.23);
> ERROR: overflow on numeric ABS(value) >= 10^2 for field with precision 4 scale 2
Vince Vielhaber ([EMAIL PROTECTED]) reports a bug with a severity of 3
The lower the number the more severe it is.
Short Description
alter table rename missing numeric type
Long Description
I start with table n1 which contains only a numeric type 4,2. Inserting a value
larger than 99.99 causes
Stephan Szabo <[EMAIL PROTECTED]> writes:
> I believe these are all the cases I saw of heap_openr with no lock
> and no check in the actual trigger functions (patch to
> hopefully elog(ERROR) instead of crashing attached).
> [ patch snipped ]
We had a discussion about that on 11-July and the cons
Stephan Szabo <[EMAIL PROTECTED]> writes:
>> Yes, this is a known bug. Two bugs actually, first being that the
>> trigger definitions don't track the rename (they should probably be
>> storing OID not relname, although that would complicate dump/restore).
> I do plan on trying to move all the ta
Gena Gurchonok <[EMAIL PROTECTED]> writes:
> When I renaming table using ALTER TABLE,
> it doesn't change table name in RI triggers. This results in backend
> crash due to invalid arguments for RI_Check trigger procedure.
Yes, this is a known bug. Two bugs actually, first being that the
trigger
I can confirm that this is a bug, and crashes in the current development
tree.
>
> POSTGRESQL BUG REPORT TEMPLATE
>
>
POSTGRESQL BUG REPORT TEMPLATE
Your name : Gena Gurchonok
Your email address : [EMAIL PROTECTED]
S
POSTGRESQL BUG REPORT TEMPLATE
Your name : Peter Hunter
Your email address : [EMAIL PRO
45 matches
Mail list logo
