Re: I/O support for composite types

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: elein <elein(at)varlena(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: I/O support for composite types
Date: 2004-06-05 20:24:05
Message-ID: 627.1086467045@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

elein <elein(at)varlena(dot)com> writes:
> Composite types will work recursively, right?
> That is a composite type inside of a composite type column?

You can have that, but I'm not intending that the I/O syntax be
explicitly aware of it. A composite type field would just be an
item (and hence would have to be suitably quoted). So it would
look something like
{somecolumn,"{anothercolumn,\"a quoted column\"}",column3}
if we go with the syntax I originally suggested.

Note that just as we offer ARRAY[] to avoid having to write this sort
of thing in SQL statements, we offer ROW() so you can synthesize
composite values without actually having to write this junk. I see
this mainly as a dump/reload representation, so I'm not too worried
about whether complex cases can be written simply.

> Does the SQL dot syntax support this nested referencing?
> Or are we only allowing one level.

You have to parenthesize to avoid ambiguity against the normal
"table.field" notation, but beyond that it works. For instance
(this is a real example with CVS tip + error check removed):

regression=# create type complex as (r float8, i float8);
CREATE TYPE
regression=# create table foo (c complex);
CREATE TABLE
regression=# insert into foo values(row(1.1, 2.2));
INSERT 154998 1
-- this doesn't work yet:
regression=# select c from foo f;
ERROR: output of composite types not implemented yet
-- here is the ambiguity problem:
regression=# select c.r from foo f;
NOTICE: adding missing FROM-clause entry for table "c"
ERROR: column c.r does not exist
-- which you can fix like this:
regression=# select (c).r, (f.c).i from foo f;
r | i
-----+-----
1.1 | 2.2
(1 row)

-- nested types work about like you'd expect:
regression=# create type quad as (c1 complex, c2 complex);
CREATE TYPE
regression=# create table bar (q quad);
CREATE TABLE
regression=# insert into bar values (row(row(1.1, 2.2), row(3.3, 4.4)));
INSERT 155006 1
regression=# select (q).c2.r from bar;
r
-----
3.3
(1 row)

> Why not just use the syntax of the insert values with parens?
> insert into tble values (...);
> is very familiar so the corresponding:
> insert into table values ( 'xxx', ('yyy', 123), 456 );
> is also easy to understand and remember: a row is being inserted.

I don't particularly care one way or the other about parens versus
braces; anyone else have an opinion on that?

However, I do want to follow the array syntax to the extent of using
double not single quotes for quoting items. Otherwise you've got a mess
when you do try to write one of these things as a SQL literal.
For instance, instead of
'{"1.1","2.2"}'::complex
you'd have to write
'{\'1.1\',\'2.2\'}'::complex
which is just painful. (In this particular example of course the inner
quotes could just be dropped entirely, but with textual fields they
would often be necessary.)

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2004-06-05 20:31:12 Re: Why hash indexes suck
Previous Message Sailesh Krishnamurthy 2004-06-05 20:15:25 Re: Why hash indexes suck