Re: Composite Types

Tom Lane wrote:
> mjp(at)ornl(dot)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(at)Yahoo(dot)com #