On Thu, Oct 03, 2002 at 04:00:32PM -0400, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Where are we with this patch?
It's done as far as I'm concerned ;-). Not sure if Hannu still wants
to argue that the behavior is wrong ... it seems fine to me though ...
I still haven't
Where are we with this patch?
---
Alvaro Herrera wrote:
On 29 Sep 2002, Hannu Krosing wrote:
On Sun, 2002-09-29 at 19:57, Tom Lane wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
I'd propose that ADD ONLY would
Bruce Momjian [EMAIL PROTECTED] writes:
Where are we with this patch?
It's done as far as I'm concerned ;-). Not sure if Hannu still wants
to argue that the behavior is wrong ... it seems fine to me though ...
regards, tom lane
---(end of
On Fri, 2002-10-04 at 01:00, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Where are we with this patch?
It's done as far as I'm concerned ;-). Not sure if Hannu still wants
to argue that the behavior is wrong ... it seems fine to me though ...
I stop arguing for now, ONLY can
Tom Lane kirjutas P, 29.09.2002 kell 04:00:
Alvaro Herrera [EMAIL PROTECTED] writes:
I have this almost ready. The thing I don't have quite clear yet is
what to do with attislocal. IMHO it should not be touched in any case,
but Hannu thinks that for symmetry it should be reset in some
Hannu Krosing [EMAIL PROTECTED] writes:
I'd propose that ADD ONLY would pull topmost attislocal up (reset it
from the (grand)child) whereas plain ADD would leave attislocal alone.
ADD ONLY? There is no such animal as ADD ONLY, and cannot be because
it implies making a parent inconsistent with
On Sun, 29 Sep 2002, Tom Lane wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
I'd propose that ADD ONLY would pull topmost attislocal up (reset it
from the (grand)child) whereas plain ADD would leave attislocal alone.
ADD ONLY? There is no such animal as ADD ONLY, and cannot be because
On Sun, 2002-09-29 at 19:57, Tom Lane wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
I'd propose that ADD ONLY would pull topmost attislocal up (reset it
from the (grand)child) whereas plain ADD would leave attislocal alone.
ADD ONLY? There is no such animal as ADD ONLY, and cannot be
On 29 Sep 2002, Hannu Krosing wrote:
On Sun, 2002-09-29 at 19:57, Tom Lane wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
I'd propose that ADD ONLY would pull topmost attislocal up (reset it
from the (grand)child) whereas plain ADD would leave attislocal alone.
ADD ONLY? There is
Alvaro Herrera [EMAIL PROTECTED] writes:
I implemented ADD ONLY as a way to add the column only in the parent
(all children should already have to column, errors if at least one
doesn't or is different atttype), while ADD adds the column to
children that don't have it and merges where already
En Thu, 19 Sep 2002 14:06:05 -0400
Tom Lane [EMAIL PROTECTED] escribió:
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane dijo:
One corner case is that I think we currently allow
create table p (f1 int);
create table c (f1 int) inherits(p);
In this case, c.f1.attisinherited
En Mon, 23 Sep 2002 09:53:08 -0400
Tom Lane [EMAIL PROTECTED] escribió:
You cannot add a column to a table that is inherited by another table
that has a column with the same name:
Yeah, this is an implementation shortcoming in ALTER ADD COLUMN: if it
finds an existing column of the same
Alvaro Herrera [EMAIL PROTECTED] writes:
I have this almost ready. The thing I don't have quite clear yet is
what to do with attislocal. IMHO it should not be touched in any case,
but Hannu thinks that for symmetry it should be reset in some cases.
My feeling would be to leave it alone in
Alvaro Herrera kirjutas K, 25.09.2002 kell 02:45:
Hannu Krosing dijo:
For me it feels assymmetric (unless we will make attislocal also int
instead of boolean ;). This assymetric nature will manifest itself when
we will have ADD COLUMN which can put back the DROP ONLY COLUMN and it
has
On Mon, 2002-09-23 at 18:41, Tom Lane wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
Alvaro Herrera kirjutas E, 23.09.2002 kell 10:30:
The former drops f1 from c, while the latter does not. It's
inconsistent.
But this is what _should_ happen.
On what grounds do you claim that? I
Hannu Krosing [EMAIL PROTECTED] writes:
1)
create table p1 (f1 int, g1 int);
create table p2 (f1 int, h1 int);
create table c () inherits(p1, p2);
drop column p2.f1; -- this DROP is in fact implicitly ONLY
Surely not? At least, I don't see why it should be
On Wed, 2002-09-25 at 04:13, Tom Lane wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
1)
create table p1 (f1 int, g1 int);
create table p2 (f1 int, h1 int);
create table c () inherits(p1, p2);
drop column p2.f1; -- this DROP is in fact implicitly ONLY
Hannu Krosing dijo:
On Wed, 2002-09-25 at 04:13, Tom Lane wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
1)
create table p1 (f1 int, g1 int);
create table p2 (f1 int, h1 int);
create table c () inherits(p1, p2);
drop column p2.f1; -- this DROP
On Wed, 2002-09-25 at 04:33, Alvaro Herrera wrote:
Hannu Krosing dijo:
On Wed, 2002-09-25 at 04:13, Tom Lane wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
1)
create table p1 (f1 int, g1 int);
create table p2 (f1 int, h1 int);
create table
Hannu Krosing dijo:
For me it feels assymmetric (unless we will make attislocal also int
instead of boolean ;). This assymetric nature will manifest itself when
we will have ADD COLUMN which can put back the DROP ONLY COLUMN and it
has to determine weather to remove the COLUMN definition
Tom Lane kirjutas P, 22.09.2002 kell 18:56:
Alvaro Herrera [EMAIL PROTECTED] writes:
Another interesting case is multiple inheritance.
create table p1 (f1 int);
create table p2 (f1 int);
create table c () inherits(p1, p2);
drop ONLY column p1.f1;
drop column p2.f1;
After
Tom Lane kirjutas P, 22.09.2002 kell 18:56:
Alvaro Herrera [EMAIL PROTECTED] writes:
Another interesting case is multiple inheritance.
create table p1 (f1 int);
create table p2 (f1 int);
create table c () inherits(p1, p2);
drop ONLY column p1.f1;
drop column p2.f1;
After
Hannu Krosing dijo:
Tom Lane kirjutas P, 22.09.2002 kell 18:56:
It seems to me that DROP ONLY should set attislocal true on each child
for which it decrements the inherit count, whether the count reaches
zero or not.
Would it then not produce a situation, which can't be reproduced
En 23 Sep 2002 10:23:06 +0200
Hannu Krosing [EMAIL PROTECTED] escribió:
Tom Lane kirjutas P, 22.09.2002 kell 18:56:
It seems to me that DROP ONLY should set attislocal true on each child
for which it decrements the inherit count, whether the count reaches
zero or not.
This would not
Alvaro Herrera kirjutas E, 23.09.2002 kell 10:06:
Hannu Krosing dijo:
Tom Lane kirjutas P, 22.09.2002 kell 18:56:
It seems to me that DROP ONLY should set attislocal true on each child
for which it decrements the inherit count, whether the count reaches
zero or not.
Would it
Alvaro Herrera kirjutas E, 23.09.2002 kell 10:30:
En 23 Sep 2002 10:23:06 +0200
Hannu Krosing [EMAIL PROTECTED] escribió:
Tom Lane kirjutas P, 22.09.2002 kell 18:56:
It seems to me that DROP ONLY should set attislocal true on each child
for which it decrements the inherit count,
Hannu Krosing [EMAIL PROTECTED] writes:
Alvaro Herrera kirjutas E, 23.09.2002 kell 10:30:
The former drops f1 from c, while the latter does not. It's
inconsistent.
But this is what _should_ happen.
On what grounds do you claim that? I agree with Alvaro: it's
inconsistent to have ONLY
Hannu Krosing [EMAIL PROTECTED] writes:
I meant
create table p1 (f1 int, f2 int);
create table p2 (f1 int, f3 int);
create table c () inherits (p1, p2);
alter table only p1 drop column f1;
If you now set c.f1.attislocal = 1 as suggested by Tom , it seems like
you have a local p1.f1
Hannu Krosing [EMAIL PROTECTED] writes:
It seems to me that DROP ONLY should set attislocal true on each child
for which it decrements the inherit count, whether the count reaches
zero or not.
Would it then not produce a situation, which can't be reproduced using
just CREATEs ? i.e. same
Alvaro Herrera [EMAIL PROTECTED] writes:
Another interesting case is multiple inheritance.
create table p1 (f1 int);
create table p2 (f1 int);
create table c () inherits(p1, p2);
drop ONLY column p1.f1;
drop column p2.f1;
After this sequence, what is the state of c.f1? Is it still
Tom Lane dijo:
It seems to me that DROP ONLY should set attislocal true on each child
for which it decrements the inherit count, whether the count reaches
zero or not. This would cause the behavior in the above case to be that
c.f1 stays around after the second drop (but can be dropped
Tom Lane dijo:
I think we could make all these cases work if we replaced attisinherited
with *two* columns, a boolean attislocal(ly defined) and a count of
(direct) inheritances. DROP ONLY would have the effect of decrementing
the count and setting attislocal to true in each direct child;
Hannu Krosing [EMAIL PROTECTED] writes:
I still think that this should be fixed in 7.3, but the inhcount
attribute should show all tables where the column is defined, not just
inherited. The default, no-inheritance case should set the column to 1.
Well, no, because then a locally defined
[ back to thinking about this patch ]
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane dijo:
One corner case is that I think we currently allow
create table p (f1 int);
create table c (f1 int) inherits(p);
In this case, c.f1.attisinherited count is 2; thus when I drop f1 from
p, it is
That seems right, but the problem I have with it is that the resulting
state of c.f1 is attisinherited = 1. This means that you cannot drop
c.f1. It seems to me that we should have this behavior:
Has anyone given much thought as to perhaps we could just drop multiple
inheritance from
Christopher Kings-Lynne wrote:
That seems right, but the problem I have with it is that the resulting
state of c.f1 is attisinherited = 1. This means that you cannot drop
c.f1. It seems to me that we should have this behavior:
Has anyone given much thought as to perhaps we could just
Bruce Momjian [EMAIL PROTECTED] writes:
Christopher Kings-Lynne wrote:
Has anyone given much thought as to perhaps we could just drop multiple
inheritance from Postgres?
I am for it. Multiple inheritance is more of a mess than a help.
I'm not agin it ... but if that's the lay of the land
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Christopher Kings-Lynne wrote:
Has anyone given much thought as to perhaps we could just drop multiple
inheritance from Postgres?
I am for it. Multiple inheritance is more of a mess than a help.
I'm not agin it ... but if
I am for it. Multiple inheritance is more of a mess than a help.
I'm not agin it ... but if that's the lay of the land then we have
no need to apply a last-minute catalog reformatting to fix a
multiple-inheritance bug. This patch is off the must fix for 7.3
list, no?
Multiple
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
I'm not agin it ... but if that's the lay of the land then we have
no need to apply a last-minute catalog reformatting to fix a
multiple-inheritance bug. This patch is off the must fix for 7.3
list, no?
I don't think a few days
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
I'm not agin it ... but if that's the lay of the land then we have
no need to apply a last-minute catalog reformatting to fix a
multiple-inheritance bug. This patch is off the must fix for 7.3
list, no?
I
The decision at hand is whether to apply a patch. You cannot say we're
not deciding now, because that is a decision...
Yes. I am saying we should not assume we are going to remove multiple
inheritance. We should apply the patch and make things a good as they
can be for 7.3.
I think
Tom Lane [EMAIL PROTECTED] writes:
Bruce Momjian [EMAIL PROTECTED] writes:
Christopher Kings-Lynne wrote:
Has anyone given much thought as to perhaps we could just drop
multiple inheritance from Postgres?
I am for it. Multiple inheritance is more of a mess than a help.
I'm not agin
Hannu Krosing [EMAIL PROTECTED] writes:
I've come upon a misbehaviour of drop column, where drop column
unconditionally drops inherited column from child tables.
What it should do is to check if the same column is not inherited from
other parents and drop it only when it is not
Hm. Seems
On Thu, 2002-09-12 at 16:14, Tom Lane wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
I've come upon a misbehaviour of drop column, where drop column
unconditionally drops inherited column from child tables.
What it should do is to check if the same column is not inherited from
other
Tom Lane dijo:
Hannu Krosing [EMAIL PROTECTED] writes:
I've come upon a misbehaviour of drop column, where drop column
unconditionally drops inherited column from child tables.
What it should do is to check if the same column is not inherited from
other parents and drop it only when it
Hannu Krosing [EMAIL PROTECTED] writes:
Hm. Seems like attisinherited should have been a count, not a boolean.
Is anyone sufficiently excited about this issue to force an initdb to
fix it?
The count approach seems definitely the right way, but a check (possibly
a slow one) can be probably
En 12 Sep 2002 17:23:41 +0200
Hannu Krosing [EMAIL PROTECTED] escribió:
The other sad thing about the current behaviour is that in addition to
being wrong it also breaks dump/reload - after dump/reload the initially
dropped column is back in c1.
I hadn't read this paragraph before. But I
Alvaro Herrera [EMAIL PROTECTED] writes:
If this is not clear, imagine the following situation:
create table p1(id int, name text);
create table p2(id2 int, name text);
create table c1(age int) inherits(p1,p2);
create table gc1() inherits (c1);
p1 and p2 have name-attisinherited=0, while
En Thu, 12 Sep 2002 23:40:21 -0400
Tom Lane [EMAIL PROTECTED] escribió:
Alvaro Herrera [EMAIL PROTECTED] writes:
If this is not clear, imagine the following situation:
create table p1(id int, name text);
create table p2(id2 int, name text);
create table c1(age int) inherits(p1,p2);
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] escribió:
Actually, there might not be a problem. c1.name can't be deleted until
both p1.name and p2.name go away, and at that point we want both c1.name
and gc1.name to go away. So as long as we don't *recursively*
51 matches
Mail list logo
