Re: Composite Types - Mailing list pgsql-general

Tom Lane wrote:
> mjp@ornl.gov writes:
> > I appreciate any help I can get on this...Recently, I've been experimenting
> > with the user defined base-types (using CREATE TYPE) with successful results.
> > But, when it comes to handling classes as composite types, things are not
> > as straight forward.
>
> The function-returning-composite-type feature is something we inherited
> from Berkeley Postgres ---- it doesn't fit into SQL92 at all,

    Right.  And  the "doesn't fit into SQL92" is why I would like
    to get rid of "composite" and "SET OF composite"  values  for
    functions.  We need to get them back in a clearly defined way
    for stored procedures, but what's possible now is  broken  in
    concept, and doesn't make much sense to me anyway.

> and I
> don't think any of the current crop of developers even understand it
> very well.  It's certainly suffering from bit-rot.  The "hobbies"
> examples in the regression tests seem to be meant to illustrate how
> it was supposed to work, but I don't find them either intelligible or
> persuasive.

    It was the so called "nested dot" syntax of PG4.2 - which was
    never released as nested dot, but was working if someone used

        attrname(func-returns-tuple(args))

    in  the  POSTQUEL  language!   The downside was, that a query
    needing more than one attrib from the func, ran  it  multiple
    times,  returning  separate  sets. Thus, JOINing over them in
    fact!

    I consider this broken from the very first  attempt,  because
    such  a function has to go into the rangetable (FROM clause).

> > If I type:
> >  select content from stuff;
> > I get:
>
> >         content
> >         -----------
> >         136585664
> >         (1 row)
>
> I believe you are looking at a numeric equivalent of a pointer-to-
> TupleTableSlot there.  Somewhere in the mists of Berkelian prehistory,
> there must have been some code that did something useful with that kind
> of function result, but I sure as heck can't find much trace of it now.

    Exactly correct. The original POSTQUEL parser had support  to
    extract a single attribute from a function returning a tuple.
    Someone also attempted to add a  targetlist  to  Func  nodes.
    Both  attempts  seemed to fail, so we ended up with a "broken
    by concept" state.

>
> I have been thinking lately that functions returning tuples might
> fit into SQL92 better as table sources.  That is, instead of
>    select foo(bar).whatdoyouwritehere ...
> we could write something like
>    select elementa,elementc+1 from foo(bar)
>
> That doesn't work at the moment, of course, but it's something we
> could think about causing to work as part of the querytree redesign
> planned for 7.2.
>
> Thoughts anyone?

    What I reffered to with "subselecting RTEs"  as  often  as  I
    could.  Seems  you  finally  got me (sorry for my bad english
    :-).

    If something is broken, fix it. If  something  is  broken  by
    concept,  fix  the  concept and reimplement the feature. This
    time, the concept is broken, so let's  first  decide  how  it
    should  appear  on  the  query level. The FROM foo(bar) above
    perfectly  fits  into  the  new  querytree  structure   we've
    outlined  during  breakfast in San-Francisco. What a time, we
    worked from breakfast until after  dinner  -  it  was  great.
    Anyway, we know that this one would fit into the new concept,
    but are we sure anything else would?

    For the rewriter, I know that VIEWs will be a nobrainer.  But
    all  other  rewriting  rules on INSERT/UPDATE/DELETE, turning
    views into tables, don't appear to be  that  easy  any  more.
    Actually we have a central rangetable, and the target is just
    "0" (meaning client) or the RTE index of the query. With  the
    new  querytree concept, we'd loose the central rangetable, so
    application of modifying rules might not be that  simple  any
    more.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #