Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL

From: Hannu Krosing <hannu(at)tm(dot)ee>
To: chris(at)bitmead(dot)com
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Mark Hollomon <mhh(at)nortelnetworks(dot)com>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-hackers(at)postgreSQL(dot)org, pgsql-sql(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL
Date: 2000-02-04 22:37:35
Message-ID: 389B54AF.9614B3D3@tm.ee
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers pgsql-sql

Chris Bitmead wrote:
>
> Tom, I agree with most of what you say. If we want to have ** be the
> default
> syntax for getting sub-columns I can live with that (for suggestion (3))
>
> But for (2), I do feel very strongly that getting sub-tuples should be
> the
> "default default", and a SET GETSUBCLASSES=true should be the default
> setting.

Then maybe we need a way to "break off" inheritance, i.e. make the inherited
table independent but retain the columns as they are at the time of breakage.

At least it could be given as an option in pg_dump. (--dump_flat_creates or
smth.)

> I've been using the postgres inheritance for a real system and I can
> say with certainty that this is a massive source of errors. Not
> wanting sub-class tuples seems rarely needed, and leaving off the "*" is
> something that too often seems forgotten. I often can trawl through
> code and realise that some query is missing the "*" but it hasn't been
> discovered yet. In fact I find that almost all queries require the "*"
> when you have a proper OO model, and not using "*" is usually laziness.

True. I also think that people who used inheritance as a create table shortcut
can most easily ensure compatibility by dumping their not-really-inherited
tables as independent. They will have to dump-relaod anyway.

> Also when adding a sub-class where there previously was none, one
> usually has to trawl through the queries and add "*" to all of them
> because as I said, there are almost never occasions where "*" is not
> required in real life OO models.
>
> So I understand the compatibility issue here, but I really feel strongly
> that this should be changed now before there really are a lot of people
> using it. Sure, have as many compatibility modes as you like, but I
> think
> this is a broken enough design that the default should be changed.
> Apparently Illustra/Informix agreed.

And they are probably the only external DB we can aim to be compatible with,
or what does SQL3 say?

----------------------
Hannu

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Ed Loehr 2000-02-04 22:39:46 Re: [GENERAL] using ID as a key
Previous Message Simon Drabble 2000-02-04 22:37:08 Re: [GENERAL] using ID as a key

Browse pgsql-hackers by date

  From Date Subject
Next Message Chris 2000-02-05 01:41:34 Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL
Previous Message Hannu Krosing 2000-02-04 22:15:11 Re: [HACKERS] Time travel

Browse pgsql-sql by date

  From Date Subject
Next Message Chris 2000-02-05 01:41:34 Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL
Previous Message Jan Wieck 2000-02-04 19:44:29 Re: [SQL] Concurrency problem