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,
I proved that you can reclaim on disk space after a DROP COLUMN with toast
tables:
test=# create table toast_test(a text, b text);
CREATE TABLE
test=# insert into toast_test values (repeat('XX', 100),
repeat('XX', 100));
INSERT 246368 1
test=# insert into toast_test values
"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:
Hi All,
This is another cut of the DROP COLUMN patch. I have split the drop
function into two parts - and now handle dependencies.
Problems:
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
dele
> 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
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 column, etc.
Will I have to add a dropped column check in everywhere tha
"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
1 - 100 of 122 matches
Mail list logo
