| From: | "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au> |
|---|---|
| To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "Hackers" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: DROP COLUMN Proposal |
| Date: | 2002-07-02 08:32:43 |
| Message-ID: | GNELIHDDFBOCMGBFGEFOIEOGCCAA.chriskl@familyhealth.com.au |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> The nice thing about this implementation approach is that most of the
> backend need not be aware of deleted columns. There are a few places in
> the parser (probably few enough to count on one hand) that will have to
> explicitly check for and reject references to dropped columns, and
> you're done. The rewriter, planner and executor are blissfully ignorant
> of the whole deal.
If you can enumerate these places without much effort, it'd be appreciated!
I found:
expandRTE() in parser/parse_relation.c
What else?
Chris
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hannu Krosing | 2002-07-02 08:40:46 | Re: aggregate that returns array |
| Previous Message | Bruce Momjian | 2002-07-02 06:18:43 | Re: [HACKERS] Page OpaqueData |