From: | Thomas Lockhart <lockhart(at)fourpalms(dot)org> |
---|---|
To: | Joe Conway <mail(at)joeconway(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: ROW features |
Date: | 2002-07-30 23:28:29 |
Message-ID: | 3D47211D.6A6ED5DD@fourpalms.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > 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
From | Date | Subject | |
---|---|---|---|
Next Message | Curt Sampson | 2002-07-30 23:35:17 | Re: Why is MySQL more chosen over PostgreSQL? |
Previous Message | Curt Sampson | 2002-07-30 23:21:09 | Re: WAL file location |