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