> Tom Lane wrote:
>
> > > 1) An imaginary field in every tuple that tells you the class it came
> > This is a good idea, but it seems to me that it'd fit into the system
> > traditions better if the pseudo-field gave the OID of the source
> > relation.
>
> This was my initial thought too, but then it occured to me that SQL
> doesn't normally deal in oids. For example you don't do a DROP TABLE
> oid;
>
> OTOH, oids are probably programmatically useful for things like ODBMSs.
>
> What do you think about having both? I know you can go from one to the
> other by joining with pg_class, but that's too inconvenient, and I can't
> make up my mind which is the better "system tradition" either.
Sure, let them have both. Why not, or you could force them to join to
pg_class for the name. That would work too.
> Ok, well compatibility is always a contentious thing. But in your case
> you are mis-using the inheritance feature.
>
> The question is, are you willing to do the (simple) changes to your
> code to cater for the common good? I'm wanting to make postgresql into a
> REAL odbms, and this is a stumbling point that will eventually affect
> 100x
> as many users as it does now (I hope :).
>
> We can also leave the old gram.y for people who want to retain
> compatibility
> for longer.
I would canvas the list to find out how many people object, and if there
are few, you may be able to get away with something in config.h.in that
they can change if they want the old behavour.
> > > Since the current PQ interface which doesn't support this notion would
> > > remain unchanged this wouldn't affect current users.
> >
> > How would you implement this without actually breaking the current
> > PQ interface?
>
> By adding new functions for use when you need to access the extra
> columns.
Whatever it is, the API has to be lean and clean.
I saw your PQnfieldsv, and that looks fine to me.
-- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
