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
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> 1. It cascade deletes objects, but it _always_ cascades, no matter what
> behaviour I specify. Also, it doesn't give me indications that it's cascade
> deleted an object.
Would you give a specific example?
> + drop table child;
> + ERROR:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > All backend functions would still use real attnum's. And I doubt that
> > backend will ever work though system views.
> > Adding them should touch _only_ CREATE TABLE, ADD COLUMN, DROP COLUMN
> > plus the system views and possibly output from SELECT(
Hannu Krosing <[EMAIL PROTECTED]> writes:
> All backend functions would still use real attnum's. And I doubt that
> backend will ever work though system views.
> Adding them should touch _only_ CREATE TABLE, ADD COLUMN, DROP COLUMN
> plus the system views and possibly output from SELECT(*), if we
On Wed, 2002-07-17 at 08:48, Hiroshi Inoue wrote:
> I sent a draft by mistake, sorry.
>
> Hannu Krosing wrote:
> >
> > On Wed, 2002-07-17 at 09:11, Hiroshi Inoue wrote:
> > > Bruce Momjian wrote:
> > >
> > > > From my perspective, when client coders like Dave Page and others say
> > > > they wou
On Wed, 2002-07-17 at 08:26, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > Also, as we have nothing like Oracles ROWNR, I think it will be quite
> > hard to have colnums without gaps in the system views, so we could
> > perhaps have a stopgap solution of adding logical column num
Tom Lane wrote:
>
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > Also, as we have nothing like Oracles ROWNR, I think it will be quite
> > hard to have colnums without gaps in the system views, so we could
> > perhaps have a stopgap solution of adding logical column numbers (
> > (pg_attribute.a
> -Original Message-
> From: Hiroshi Inoue [mailto:[EMAIL PROTECTED]]
> Sent: 17 July 2002 05:12
> To: Bruce Momjian
> Cc: Christopher Kings-Lynne; Tom Lane; Rod Taylor;
> PostgreSQL-development
> Subject: Re: [HACKERS] DROP COLUMN
>
>
> > >Fro
I sent a draft by mistake, sorry.
Hannu Krosing wrote:
>
> On Wed, 2002-07-17 at 09:11, Hiroshi Inoue wrote:
> > Bruce Momjian wrote:
> >
> > > From my perspective, when client coders like Dave Page and others say
> > > they would prefer the flag to the negative attno's, I don't have to
> > > und
On Wed, 2002-07-17 at 11:29, Christopher Kings-Lynne wrote:
> > > But those (few) apps that still need intimate knowledge about postrges'
> > > internals will always have to query the original system _tables_.
> > >
> > > Also, as we have nothing like Oracles ROWNR, I think it will be quite
> > >
> > But those (few) apps that still need intimate knowledge about postrges'
> > internals will always have to query the original system _tables_.
> >
> > Also, as we have nothing like Oracles ROWNR, I think it will be quite
> > hard to have colnums without gaps in the system views,
>
> Agreed. Ho
Hannu Krosing wrote:
>
> On Wed, 2002-07-17 at 09:11, Hiroshi Inoue wrote:
> > Bruce Momjian wrote:
> >
> > > From my perspective, when client coders like Dave Page and others say
> > > they would prefer the flag to the negative attno's, I don't have to
> > > understand. I just take their word fo
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Also, as we have nothing like Oracles ROWNR, I think it will be quite
> hard to have colnums without gaps in the system views, so we could
> perhaps have a stopgap solution of adding logical column numbers (
> (pg_attribute.attlognum) that will be chang
On Wed, 2002-07-17 at 09:11, Hiroshi Inoue wrote:
> Bruce Momjian wrote:
>
> > From my perspective, when client coders like Dave Page and others say
> > they would prefer the flag to the negative attno's, I don't have to
> > understand. I just take their word for it.
>
> do they really love to
Tom Lane wrote:
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > Have I ever mentioned that negative attno's is better
> > than the attisdropped flag implemetation in the handling
> > of gaps in attnums ?
>
> How so? I don't see any improvement ...
Sorry please ignore my above words if it has
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> Have I ever mentioned that negative attno's is better
> than the attisdropped flag implemetation in the handling
> of gaps in attnums ?
How so? I don't see any improvement ...
regards, tom lane
---(end
Tom Lane wrote:
>
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> What I asked you is what *harder to fix* means.
>
> > Uh, some said that having attno's like 1,2,3,5,7,8,9 with gaps would
> > cause coding problems in client applications, and that was easier to
> > have the numbers as 1-9 and ch
Bruce Momjian wrote:
>
> Hiroshi Inoue wrote:
> > Bruce Momjian wrote:
> > >
> > > Hiroshi Inoue wrote:
>
> > > > BTW would we do nothing for clients after all ?
> > >
> > > Clients will now need to check that dropped flag.
> >
> > Clients would have to check the flag everywhere
> > pg_attribute
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> What I asked you is what *harder to fix* means.
> Uh, some said that having attno's like 1,2,3,5,7,8,9 with gaps would
> cause coding problems in client applications, and that was easier to
> have the numbers as 1-9 and check a flag if the column is d
Hiroshi Inoue wrote:
> Bruce Momjian wrote:
> >
> > Hiroshi Inoue wrote:
> > > > Makes sense. Of course, we could make a syscache that didn't return
> > > > system columns either.
> > > >
> > > > Actually, the original argument for negative attno's for dropped columns
> > > > was exactly for thi
Bruce Momjian wrote:
>
> Hiroshi Inoue wrote:
> > > Makes sense. Of course, we could make a syscache that didn't return
> > > system columns either.
> > >
> > > Actually, the original argument for negative attno's for dropped columns
> > > was exactly for this case, that the system column check w
On Tue, 2002-07-16 at 18:30, Bruce Momjian wrote:
> Hiroshi Inoue wrote:
> > > Makes sense. Of course, we could make a syscache that didn't return
> > > system columns either.
> > >
> > > Actually, the original argument for negative attno's for dropped columns
> > > was exactly for this case, th
Hiroshi Inoue wrote:
> > Makes sense. Of course, we could make a syscache that didn't return
> > system columns either.
> >
> > Actually, the original argument for negative attno's for dropped columns
> > was exactly for this case, that the system column check would catch
> > dropped columns too
> -Original Message-
> From: Bruce Momjian
>
> Christopher Kings-Lynne wrote:
> > > Uh, then what? The only idea I had was to set a static boolean
> > > variable in
> > > syscache.c that controls whether droppped columns are
> returned, and have
> > > a enable/disable functions that can
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> Actually - are you certain that every command uses a SearchSysCache and not
> some other weirdness?
They probably don't. You'll have to look closely at places that use the
TupleDesc from a relcache entry.
regards, t
Christopher Kings-Lynne wrote:
> > > In fact, looking at it logically...if all the commands currently are
> > > required to check that they're not modifiying a system column,
> > then why not
> > > add the requirement that they must also not modify dropped
> > columns? I can
> > > do a careful do
> > In fact, looking at it logically...if all the commands currently are
> > required to check that they're not modifiying a system column,
> then why not
> > add the requirement that they must also not modify dropped
> columns? I can
> > do a careful doc search and try to make sure I've touched
> Actually, the original argument for negative attno's for dropped columns
> was exactly for this case, that the system column check would catch
> dropped columns too, but it causes other problems that are harder to fix
> so we _dropped_ the idea.
Well, negative attnums are a good idea and yes, y
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Definitely *not*; I don't want to kluge up every call to SearchSysCache
> >> with a feature that's only relevant to a small number of them.
>
> > Uh, then what?
>
> Then we make a wrapper function. Something li
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Definitely *not*; I don't want to kluge up every call to SearchSysCache
>> with a feature that's only relevant to a small number of them.
> Uh, then what?
Then we make a wrapper function. Something like
GetUndeletedColumnBy
Christopher Kings-Lynne wrote:
> > Uh, then what? The only idea I had was to set a static boolean
> > variable in
> > syscache.c that controls whether droppped columns are returned, and have
> > a enable/disable functions that can turn it on/off. The only problem is
> > that an elog inside a sys
> Uh, then what? The only idea I had was to set a static boolean
> variable in
> syscache.c that controls whether droppped columns are returned, and have
> a enable/disable functions that can turn it on/off. The only problem is
> that an elog inside a syscache lookup would leave that value set.
Tom Lane wrote:
> "Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> >> I agree that a wrapper function is probably an appropriate solution,
> >> but only some of the calls of SearchSysCache should use it.
>
> > What like add another parameter to SearchSysCache*?
>
> Definitely *not*; I don
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
>> I agree that a wrapper function is probably an appropriate solution,
>> but only some of the calls of SearchSysCache should use it.
> What like add another parameter to SearchSysCache*?
Definitely *not*; I don't want to kluge up every call
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Excellent idea. That's how temp tables worked, by bypassing the
> syscache. I wonder if you could just prevent dropped columns from being
> returned by the syscache. That may work just fine.
No, it will break all the places that need to see dropped c
Rod Taylor wrote:
> On Mon, 2002-07-15 at 11:30, Christopher Kings-Lynne wrote:
> > OK, more DROP COLUMN funny business:
> >
> > Assuming that selects, updates and deletes all ignore the dropped column,
> > what happens with things like alter table statements?
> >
> > You can still quite happily
On Mon, 2002-07-15 at 11:30, Christopher Kings-Lynne wrote:
> OK, more DROP COLUMN funny business:
>
> Assuming that selects, updates and deletes all ignore the dropped column,
> what happens with things like alter table statements?
>
> You can still quite happily set the default for a dropped c
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
>> That was my first thought also, but then the wrong attnum would be used
>> in the "make_var". Ugh. I think what Chris needs to do is extend the
>> eref data structure so that there can be placeholders for dropped
>> attributes. Perhaps NU
> "Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> >> That was my first thought also, but then the wrong attnum would be used
> >> in the "make_var". Ugh. I think what Chris needs to do is extend the
> >> eref data structure so that there can be placeholders for dropped
> >> attributes.
> That was my first thought also, but then the wrong attnum would be used
> in the "make_var". Ugh. I think what Chris needs to do is extend the
> eref data structure so that there can be placeholders for dropped
> attributes. Perhaps NULLs could be included in the list, and then the
> code wou
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
>> What of
>> SELECT a,c,d FROM test
>> I'll bet that doesn't work at all...
> Yeah, broken. Damn.
Yup. That loop we were just looking at needs to derive the correct
attnum when it matches a column name. If you remove deleted columns
from
> > test=# create table test (a int4, b int4, c int4, d int4);
> > CREATE TABLE
> > test=# insert into test values (1,2,3,4);
> > INSERT 16588 1
> > test=# alter table test drop b;
> > ALTER TABLE
> > test=# select * from test;
> > a | d | d
> > ---+---+---
> > 1 | 3 | 4
> > (1 row)
>
> What of
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
>> Are you checking access to columns that're to the right of the one
>> dropped?
> OK, interesting:
> test=# create table test (a int4, b int4, c int4, d int4);
> CREATE TABLE
> test=# insert into test values (1,2,3,4);
> INSERT 16588 1
> te
Christopher Kings-Lynne wrote:
> > > I am still looking but perhaps you could supress dropped columns from
> > > getting into eref in the first place.
> >
> > OK, that's done. I'm working on not allowing dropped columns in UPDATE
> > targets now.
>
> OK, I've fixed it so that dropped columns can
1 - 100 of 117 matches
Mail list logo
