From: | elein <elein(at)varlena(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | elein <elein(at)varlena(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: I/O support for composite types |
Date: | 2004-06-05 21:34:56 |
Message-ID: | 20040605143456.N11485@cookie.varlena.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Good reason. Now I'm excited. I'll download and run
tests and try to do a write up in general bits next week.
cheers,
elein
On Sat, Jun 05, 2004 at 05:00:24PM -0400, Tom Lane wrote:
> I wrote:
> > regression=# insert into bar values (row(row(1.1, 2.2), row(3.3, 4.4)));
>
> BTW, I forgot to mention that the keyword ROW is optional as long as
> you've got at least two items in the row expression, so the above can
> be simplified to
>
> regression=# insert into bar values (((1.1, 2.2), (3.3,4.4)));
> INSERT 155011 1
>
> Some other examples:
>
> regression=# select (1,2)::complex;
> ERROR: output of composite types not implemented yet
> regression=# select cast ((1,2) as complex);
> ERROR: output of composite types not implemented yet
>
> Looking at these, it does seem like it would be natural to get back
>
> complex
> ---------
> (1,2)
>
> so I'll now agree with you that the I/O syntax should use parens not
> braces as the outer delimiters.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Hallgren | 2004-06-05 21:34:58 | Re: I/O support for composite types |
Previous Message | Tom Lane | 2004-06-05 21:00:24 | Re: I/O support for composite types |