Re: [SQL] Proposed Changes to PostgreSQL

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: chris(at)bitmead(dot)com
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgreSQL(dot)org, pgsql-sql(at)postgreSQL(dot)org
Subject: Re: [SQL] Proposed Changes to PostgreSQL
Date: 2000-02-03 04:02:44
Message-ID: 200002030402.XAA03844@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers pgsql-sql

> 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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Bruce Momjian 2000-02-03 04:03:14 Re: [GENERAL] Proposed Changes to PostgreSQL
Previous Message Stephane FILLON 2000-02-03 03:59:10 RE: [GENERAL] PL/pgSQL syntax/usage question

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2000-02-03 04:03:14 Re: [GENERAL] Proposed Changes to PostgreSQL
Previous Message Bruce Momjian 2000-02-03 03:58:41 Re: [HACKERS] Re: [SQL] Re: [GENERAL] Proposed Changes to PostgreSQL

Browse pgsql-sql by date

  From Date Subject
Next Message Bruce Momjian 2000-02-03 04:03:14 Re: [GENERAL] Proposed Changes to PostgreSQL
Previous Message Bruce Momjian 2000-02-03 03:58:41 Re: [HACKERS] Re: [SQL] Re: [GENERAL] Proposed Changes to PostgreSQL