Greg Stark <[EMAIL PROTECTED]> writes:
> Following this path, perhaps the array i/o syntax should be changed to
> use []s
I would think about that if there weren't compatibility issues to worry
about, but in practice the pain from such an incompatible change would
vastly outweigh the benefit.
> a
> > 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), (
Tom Lane wrote:
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 car
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 ment
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.
elein <[EMAIL PROTECTED]> 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 hav
Tom Lane wrote:
Thomas Hallgren <[EMAIL PROTECTED]> writes:
Why not use standard C semantics for the textual representation with
your addition that empty items are NULL?
This isn't C, it's SQL; and I think the array I/O representation is a
closer precedent for us than the C standard.
In any case,
Composite types will work recursively, right?
That is a composite type inside of a composite type column?
Does the SQL dot syntax support this nested referencing?
Or are we only allowing one level.
Why not just use the syntax of the insert values with parens?
insert into tble values (...
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> Why not use standard C semantics for the textual representation with
> your addition that empty items are NULL?
This isn't C, it's SQL; and I think the array I/O representation is a
closer precedent for us than the C standard.
In any case, how much o
Tom Lane wrote:
I am inclined to define this similarly to the representation for arrays;
however, we need to allow for NULLs. I suggest
{item,item,item}
The separator is always comma (it can't be type-specific since the items
might have different types). Backslashes and double quotes can
There's just one thing left to do to make composite types useful as
table columns: we have to support I/O of composite values. (Without
this, pg_dump would fail to work on such columns, rendering them not
very useful in the real world.) This means we have to hammer out a
definition for what the e
11 matches
Mail list logo
