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
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, "O
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 bro
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
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 wher
On Mon, 2002-09-30 at 00:05, 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 pull topmost attislocal up (reset it
> > > > from the (grand)child)
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 ON
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 cann
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 b
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 w
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
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
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 t
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.f
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 i
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
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 in
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 p
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 implic
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 shou
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 c
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
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
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 ON
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 inher
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.
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
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 repro
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
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
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
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
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 chil
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
Tom Lane kirjutas R, 20.09.2002 kell 04:49:
> 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
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.
> > 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
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"
> >> li
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 f
> > > 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?
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
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
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
> 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 Post
[ 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 fro
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 *recursivel
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) inheri
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
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
Tom Lane dijo:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
>
> > The count approach seems definitely the right way, but a check (possibly
> > a slow one) can be probably done without initdb.
>
> Slow, complicated to code, and deadlock-prone (since you'd have to
> acquire locks on the other par
On Thu, 12 Sep 2002, scott.marlowe wrote:
> Agreed.
>
> Actually, an argument could likely be made that changes that require
> initdb should be done as early as possible since the later the change the
> more people there will be to test the change, and there will be fewer
> people who actuall
On Thu, 12 Sep 2002, Matthew T. OConnor wrote:
> > > The count approach seems definitely the right way, but a check (possibly
> > > a slow one) can be probably done without initdb.
> >
> > We can certainly do the proper fix in 7.4; do we consider this bug
> > important enough to do an initdb for
> > The count approach seems definitely the right way, but a check (possibly
> > a slow one) can be probably done without initdb.
>
> We can certainly do the proper fix in 7.4; do we consider this bug
> important enough to do an initdb for 7.3beta2? I don't have a strong
> feeling either way abou
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
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 on
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
> >
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. See
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
Here is the test case:
hannu=# create table p1(id int,
58 matches
Mail list logo
