Re: I/O support for composite types

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 be used
> in the usual ways to quote characters in the item strings. If an item
> string is completely empty it is taken as NULL; to write an actual
> empty-string value, you must write "". There is an ambiguity whether
> '{}' represents a zero-column row or a one-column row containing a NULL,
> but I don't think this is a problem since the input converter will
> always know how many columns it is expecting.
>
> There are a couple of fine points of the array I/O behavior that I think
> we should not emulate. One is that leading whitespace in an item string
> is discarded. This seems inconsistent, mainly because trailing
> whitespace isn't discarded. In the cases where it really makes sense to
> discard whitespace (namely numeric datatypes), the underlying datatype's
> input converter can do that just fine, and so I suggest that the record
> converter itself should not discard whitespace. It seems OK to ignore
> whitespace before and after the outer braces, however.
>
> The other fine point has to do with double quoting. In the array code,
> {a"b""c"d}
> is legal input representing an item 'abcd'. I think it would be more
> consistent with usual SQL conventions to treat it as meaning 'ab"cd',
> that is a doubled double quote within double quotes should represent a
> double quote not nothing. Anyone have a strong feeling one way or the
> other?

Why not use standard C semantics for the textual representation with
your addition that empty items are NULL? It becomes fairly stright
forward, IMO highly readable, and the rules to define both arrays and
complex types are well known and documented.

Here's an array of two composite elements of the same type. The last two
items of the second element is NULL. The type is {int, double, string, char}

{
{12, 123.4, "some string with \"a qouted string\" inside of it", 'c'},
{13, -3.2,,}
}

This will also allow you to distinguish strings from identifiers. That
might prove extremely important if you ever plan to serialize self
referencing structures (a structure could then represent itself as
ref_<oid> or something and thereby refer to itself).

Kind regards,

Thomas Hallgren