"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 COLUMN_
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 f
> 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 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, howe
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Christopher Kings-Lynne wrote:
>> 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 unfo
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
"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
> > 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:
>> 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
> 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:
> >> 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.
"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
14 matches
Mail list logo
