Thread: Re: [DOCS] Inheritance docs error.

Re: [DOCS] Inheritance docs error.

From
Tom Lane
Date:
Peter Eisentraut <peter_e@gmx.net> writes:
>>>> They are all correct:  UNDER is the new SQL99 syntax, INHERITS is the
>>>> traditional Postgres syntax.
>>
>> Current docs do appear to be erroneous: they claim the UNDER phrase goes
>> where INHERIT does, which is not what the grammar thinks.  I haven't
>> looked at SQL99 to see which is right.

> The grammar appears to be correct to the extent that SQL99 wants the UNDER
> before the column list, so I corrected the documentation at that point.
> However, the syntax as a whole is not SQL99-compliant.

Hmm.  After looking at the SQL99 syntax, it seems that what we've done
with our grammar is to take the old INHERITS functionality and plaster
a vaguely-SQL-like syntax on it.  I have to wonder whether this is a
good idea.  I think it'll get in the way when and if we want to offer
true SQL99 UNDER behavior, which is only marginally related to INHERITS.
(In particular, SQL99 seems to want an explicit specification of the
structured type that's being inherited.)

I am strongly inclined to rip out the pseudo-UNDER clause and support
only the old-style INHERITS syntax for 7.1.  UNDER is adding no
functionality and I think we will eventually regret using an SQL keyword
for non-SQL semantics.

Comments?

            regards, tom lane

Re: [DOCS] Inheritance docs error.

From
Peter Eisentraut
Date:
Tom Lane writes:

> I am strongly inclined to rip out the pseudo-UNDER clause and support
> only the old-style INHERITS syntax for 7.1.  UNDER is adding no
> functionality and I think we will eventually regret using an SQL keyword
> for non-SQL semantics.

I agree.

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/



Re: [DOCS] Inheritance docs error.

From
Hannu Krosing
Date:
Tom Lane wrote:
>
> Peter Eisentraut <peter_e@gmx.net> writes:
> >>>> They are all correct:  UNDER is the new SQL99 syntax, INHERITS is the
> >>>> traditional Postgres syntax.
> >>
> >> Current docs do appear to be erroneous: they claim the UNDER phrase goes
> >> where INHERIT does, which is not what the grammar thinks.  I haven't
> >> looked at SQL99 to see which is right.
>
> > The grammar appears to be correct to the extent that SQL99 wants the UNDER
> > before the column list, so I corrected the documentation at that point.
> > However, the syntax as a whole is not SQL99-compliant.
>
> Hmm.  After looking at the SQL99 syntax, it seems that what we've done
> with our grammar is to take the old INHERITS functionality and plaster
> a vaguely-SQL-like syntax on it.  I have to wonder whether this is a
> good idea.  I think it'll get in the way when and if we want to offer
> true SQL99 UNDER behavior, which is only marginally related to INHERITS.
> (In particular, SQL99 seems to want an explicit specification of the
> structured type that's being inherited.)
>
> I am strongly inclined to rip out the pseudo-UNDER clause and support
> only the old-style INHERITS syntax for 7.1.  UNDER is adding no
> functionality and I think we will eventually regret using an SQL keyword
> for non-SQL semantics.
>
> Comments?

I'm all for it, as UNDER and INHERITS seem to offer different benefits.

As UNDER is strictly single-inheritance, the best way to implement it
seems
to use a single file for all tables "under" the root table which will
give us
almost automatic primary keys and other constraints which are much
trickier to
implement or even to define for multimple inheritance (e.g. how do you
"inherit"
a primary key from two parents' primary keys)

So just leave it out until we have a _real_ under implementation, or
else
someone will use it and lock us into backwards-compatibility trap.


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

Re: Re: [DOCS] Inheritance docs error.

From
"Robert B. Easter"
Date:
I thought about this UNDER/INHERITS stuff months ago and wrote this file:

http://www.comptechnews.com/~reaster/pgoo.html

It might have something of value to someone.  I'm not sure everything in the
file is correct though.

I remember the idea of UNDER is to be compatible with storing data from a
Java program, which only does single inheritance of classes and multiple for
interface types.  UNDER and INHERIT are different enough to be completely
separate and coexisting.

It's an interesting subject, but I don't have anything much else to say about
this topic since I have no plans to implement it!  I'd have to study postgres
for another year probably first! :)


On Sunday 31 December 2000 22:57, Hannu Krosing wrote:
> Tom Lane wrote:
> > Peter Eisentraut <peter_e@gmx.net> writes:
> > >>>> They are all correct:  UNDER is the new SQL99 syntax, INHERITS is
> > >>>> the traditional Postgres syntax.
> > >>
> > >> Current docs do appear to be erroneous: they claim the UNDER phrase
> > >> goes where INHERIT does, which is not what the grammar thinks.  I
> > >> haven't looked at SQL99 to see which is right.
> > >
> > > The grammar appears to be correct to the extent that SQL99 wants the
> > > UNDER before the column list, so I corrected the documentation at that
> > > point. However, the syntax as a whole is not SQL99-compliant.
> >
> > Hmm.  After looking at the SQL99 syntax, it seems that what we've done
> > with our grammar is to take the old INHERITS functionality and plaster
> > a vaguely-SQL-like syntax on it.  I have to wonder whether this is a
> > good idea.  I think it'll get in the way when and if we want to offer
> > true SQL99 UNDER behavior, which is only marginally related to INHERITS.
> > (In particular, SQL99 seems to want an explicit specification of the
> > structured type that's being inherited.)
> >
> > I am strongly inclined to rip out the pseudo-UNDER clause and support
> > only the old-style INHERITS syntax for 7.1.  UNDER is adding no
> > functionality and I think we will eventually regret using an SQL keyword
> > for non-SQL semantics.
> >
> > Comments?
>
> I'm all for it, as UNDER and INHERITS seem to offer different benefits.
>
> As UNDER is strictly single-inheritance, the best way to implement it
> seems
> to use a single file for all tables "under" the root table which will
> give us
> almost automatic primary keys and other constraints which are much
> trickier to
> implement or even to define for multimple inheritance (e.g. how do you
> "inherit"
> a primary key from two parents' primary keys)
>
> So just leave it out until we have a _real_ under implementation, or
> else
> someone will use it and lock us into backwards-compatibility trap.
>
>
> --------------
> Hannu

--
-------- Robert B. Easter  reaster@comptechnews.com ---------
- CompTechNews Message Board   http://www.comptechnews.com/ -
- CompTechServ Tech Services   http://www.comptechserv.com/ -
---------- http://www.comptechnews.com/~reaster/ ------------

Re: Re: [DOCS] Inheritance docs error.

From
Thomas Lockhart
Date:
> I am strongly inclined to rip out the pseudo-UNDER clause and support
> only the old-style INHERITS syntax for 7.1.  UNDER is adding no
> functionality and I think we will eventually regret using an SQL keyword
> for non-SQL semantics.

I agree with you, Hannu, et al. If it isn't making a good effort in
truely supporting SQL9x, then it isn't yet worth having in the parser.

                    - Thomas

Re: Re: [DOCS] Inheritance docs error.

From
Tom Lane
Date:
"Robert B. Easter" <reaster@comptechnews.com> writes:
> I thought about this UNDER/INHERITS stuff months ago and wrote this file:
> http://www.comptechnews.com/~reaster/pgoo.html

Good analysis, especially the fundamental point that UNDER is only
designed to support single inheritance, whereas INHERITS allows multiple
inheritance.

The current grammar treats UNDER as interchangeable with INHERITS,
including allowing multiple names to be listed as UNDER.  That would
certainly be a fatal mistake, since it would create a backwards
compatibility problem as soon as we wanted to support any of the
features of UNDER that require single inheritance.

> I'm not sure everything in the file is correct though.

One thing that bothered me is that my reading of the SQL99 draft
disallows the UNDER syntax you are using.  I read:

         <table definition> ::=
              CREATE [ <table scope> ] TABLE <table name>
                <table contents source>
                [ ON COMMIT <table commit action> ROWS ]

         <table contents source> ::=
                <table element list>
              | OF <user-defined type>
                  [ <subtable clause> ]
                  [ <table element list> ]

         <subtable clause> ::=
              UNDER <supertable clause>

         <supertable clause> ::= <supertable name>

It looks to me like "UNDER <table name>" cannot appear without a
preceding "OF <user-defined type>".  I am not clear on the semantic
implications of the OF clause.


Anyway, we seem to have a clear consensus to pull the UNDER clause from
the grammar and stick with INHERITS for 7.1.  I will take care of that
in the next day or so.

            regards, tom lane

Re: Re: [DOCS] Inheritance docs error.

From
Hannu Krosing
Date:
Tom Lane wrote:
>
> One thing that bothered me is that my reading of the SQL99 draft
> disallows the UNDER syntax you are using.  I read:
>
>          <table definition> ::=
>               CREATE [ <table scope> ] TABLE <table name>
>                 <table contents source>
>                 [ ON COMMIT <table commit action> ROWS ]
>
>          <table contents source> ::=
>                 <table element list>
>               | OF <user-defined type>
>                   [ <subtable clause> ]
>                   [ <table element list> ]
>
>          <subtable clause> ::=
>               UNDER <supertable clause>
>
>          <supertable clause> ::= <supertable name>
>
> It looks to me like "UNDER <table name>" cannot appear without a
> preceding "OF <user-defined type>".  I am not clear on the semantic
> implications of the OF clause.

to me it seems that only this is OR-d : <table element list> | OF
<user-defined type>

and the rest ([ <subtable clause> ],[ <table element list> ])is just
optional

> Anyway, we seem to have a clear consensus to pull the UNDER clause from
> the grammar and stick with INHERITS for 7.1.  I will take care of that
> in the next day or so.

Good.

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

Re: Re: [DOCS] Inheritance docs error.

From
Tom Lane
Date:
Hannu Krosing <hannu@tm.ee> writes:
> Tom Lane wrote:
> >          <table contents source> ::=
> >                 <table element list>
> >               | OF <user-defined type>
> >                   [ <subtable clause> ]
> >                   [ <table element list> ]
>
> to me it seems that only this is OR-d : <table element list> | OF
> <user-defined type>
> and the rest ([ <subtable clause> ],[ <table element list> ])is just
> optional

The grammar is less than perfectly clear, isn't it?  But that reading
just doesn't make any sense, because it would allow <table contents
source> to be (among other things) <table element list> <table element list>
which I am sure is not what they intend.  The last line has to be part
of the second alternative, it seems to me, and therefore the
next-to-last line is too.

            regards, tom lane

Re: Re: [DOCS] Inheritance docs error.

From
Peter Eisentraut
Date:
Hannu Krosing writes:

> >          <table contents source> ::=
> >                 <table element list>
> >               | OF <user-defined type>
> >                   [ <subtable clause> ]
> >                   [ <table element list> ]

> to me it seems that only this is OR-d : <table element list> | OF
> <user-defined type>
>
> and the rest ([ <subtable clause> ],[ <table element list> ])is just
> optional

Nope.  In that case it would read

         <table contents source> ::=
              {  <table element list>
              | OF <user-defined type> }
                  [ <subtable clause> ]
                  [ <table element list> ]

because ISO/IEC 9075-1:1999 section 6.1 says:

         |     The alternative operator. The vertical bar indicates that the
               portion of the formula following the bar is an alternative
               to the portion preceding the bar. If the vertical bar appears
               at a position where it is not enclosed in braces or square
               brackets, it specifies a complete alternative for the element
               defined by the production rule. If the vertical bar appears
               in a portion of a formula enclosed in braces or square
               brackets, it specifies alternatives for the contents of the
               innermost pair of such braces or brackets.

--
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/