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
57 matches
Mail list logo
