Thread: ROW features

I have implemented the ROW keyword, but am not sure that I've gotten
what the spec intends to be the full scope of functionality. It may be
that I've missed the main point completely :)

If someone has the time and interest I'd appreciate it if they would go
through the SQL99 spec and see what they deduce about the ROW keyword
and the underlying functionality which goes along with it. It seemed to
enable (at least) having an explicit keyword to introduce row clauses
(thus eliminating the ambiguity between a single-column row and a
parenthesized expression) and that is what I implemented. But I get
hints from reading the spec that there may be more involved, including
(perhaps) something like name/value pairs in a row expression.

afaict the spec is not at all verbose about this, and is very dense and
obtuse where it does discuss it. So more pairs of eyes would be greatly
appreciated...
                  - Thomas

Thomas Lockhart wrote:
> I have implemented the ROW keyword, but am not sure that I've gotten
> what the spec intends to be the full scope of functionality. It may be
> that I've missed the main point completely :)
> 
> If someone has the time and interest I'd appreciate it if they would go
> through the SQL99 spec and see what they deduce about the ROW keyword
> and the underlying functionality which goes along with it. It seemed to
> enable (at least) having an explicit keyword to introduce row clauses
> (thus eliminating the ambiguity between a single-column row and a
> parenthesized expression) and that is what I implemented. But I get
> hints from reading the spec that there may be more involved, including
> (perhaps) something like name/value pairs in a row expression.
> 
> afaict the spec is not at all verbose about this, and is very dense and
> obtuse where it does discuss it. So more pairs of eyes would be greatly
> appreciated...

Obtuse indeed!

Under 6 Scalar expressions -> 6.1 <data type> I see (my take):   ROW ( column_name data_type [,...] )
and under 7 Query expressions -> 7.1 <row value constructor>:   ROW ( value_expression [,...] )

Can you send examples of how these would be used?

It seems this is related to the RECORD pseudo type patch I just 
submitted (see:   http://archives.postgresql.org/pgsql-patches/2002-07/msg00286.php
) and the CREATE composite type proposal I sent in last night (no link 
in the archives yet), but it isn't clear to if or how anything would 
need to be changed.

Thanks,

Joe

> > I have implemented the ROW keyword, but am not sure that I've gotten
> > what the spec intends to be the full scope of functionality. It may be
> > that I've missed the main point completely :)
...
> > afaict the spec is not at all verbose about this, and is very dense and
> > obtuse where it does discuss it. So more pairs of eyes would be greatly
> > appreciated...
> Obtuse indeed!
> Under 6 Scalar expressions -> 6.1 <data type> I see (my take):
>     ROW ( column_name data_type [,...] )
> and under 7 Query expressions -> 7.1 <row value constructor>:
>     ROW ( value_expression [,...] )
> Can you send examples of how these would be used?

No! :)

OK, "section 7" <row value constructor> is what I implemented. afaict
that allows things like

SELECT ROW (1) IN (SELECT A FROM T);

which would otherwise be disallowed in our grammar because

SELECT (1) IN ...

is ambiguous as to whether it is a single-column row or a parenthesized
expression.

The other usage for "section 6" <data type> is pretty obscure to me, but
I *think* it has to do with RECORD types or UDTs built using SQL99
commands and consisting of structures of other types (I forget the
terminology; is that a RECORD type?).

I didn't implement the latter stuff, but it looks like we can get to it
later. When I was looking recently that's all I noticed and was worried
that I'd completely missed the boat...
                       - Thomas