Re: column ordering, was Re: [PATCHES] Enums patch v2 - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: column ordering, was Re: [PATCHES] Enums patch v2
Date
Msg-id 20061220041250.GF24675@kenobi.snowman.net
Whole thread Raw
In response to Re: column ordering, was Re: [PATCHES] Enums patch v2  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: column ordering, was Re: [PATCHES] Enums patch v2  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> If you can show me a reasonably bulletproof or machine-checkable way to
> keep the two kinds of column numbers distinct, I'd be all for it.  But
> without that, the answer will remain no.

Force references to go through macros which implement the lookup for the
appropriate type?  ie: LOGICAL_COL(table_oid,2) vs.
PHYSICAL_COL(table_oid,1)  Perhaps that's too simplistic.  I guess my
feeling on how this would be approached would be that there'd simply be
a level where logical columns are used and a seperate level where
physical columns are used.  Perhaps the storage layer isn't well enough
abstracted for that though.  Another possibility would be to declare
seperate structures for them (or do something else along those lines,
aka, whatever it is the Linux kernel does) and get the compiler to whine
whenever the typing isn't followed correctly.

Just tossing some thoughts out there, I'd *really* like to have
movable-columns and the ability to add columns in where they're most
appropriate instead of off on the end...  If we can settle on an
approach to deal with Tom's concern I'd be willing to look at updating
the patch to implement it though it's not really high enough that I can
promise anything.
Thanks,
    Stephen

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: PQencryptPassword() and encoding
Next
From: Bruce Momjian
Date:
Subject: Re: Companies Contributing to Open Source