On Thu, Dec 16, 2010 at 5:03 AM, Florian Pflug <fgp@phlo.org> wrote:
> On Dec16, 2010, at 02:51 , Daniele Varrazzo wrote:
>> 1. do I get enough info in the PGresult to inspect anonymous composite types?
> You just get the composite value, as you discovered. In text mode, that means
> only the composite string value, which contains no information about the
> individual field's types. In binary mode, however, the structure of such a
> composite value appears to be
>
> <number of fields: 4 bytes>
> [for each field]
> <OID of field's type: sizeof(Oid) bytes>
> [if value is NULL]
> <-1: 4 bytes>
> [else]
> <length of value: 4 bytes>
> <value: <length> bytes>
> [end if]
> [end for]
>
> according to a quick glance over record_send() in
> src/backend/utils/rowtypes.c. You'll want to double-check this, it really
> was a *very* quick glance ;-)
>
> The field's values are, again, in binary format, not text! AFAIK you *can*
> decide whether to use text for binary mode on a per-field basis when you
> execute a query, but once you request a field of type "record" to be
> transferred as binary, you'll have to be able to deal with arbitrary types
> sent as binary since you won't know which types the record might contain.
> Which isn't easy, because the binary representation of some types
> (like float I think) is machine-dependent :-(
>
>> 2. do I get such info for composite types for which I have schema info
>> in the catalog, without issuing a second query? (which I don't feel it
>> is a driver's job)
> No. Your only option is probably to query this information once and cache
> it. Knowing when to invalidate that cache isn't easy, though - but since
> type's probably don't change too often, some compromise will hopefully do.
>
>> 3. is there any libpq facility to split the string returned after a
>> composite types into its single components, without having to write a
>> parser to deal with commas and quotes?
> Not that I'd know of. There is, however, a project called libpqtypes
> which I think deal with things like that. I've never used it, though,
> so I can't say whether it fits your needs or not.
yeah -- what libpqtypes does is expose composites and arrays (and
composites of arrays) as a 'result within a result'. You register the
composite type by name, then you can create a PGresult that exposes
the composite as if itself were a returned set -- then you get to use
the regular libpq access functions to get the oid is null, etc. This
process can nest of course. You might want to check it out.
libpqtypes also always requests data in binary. this would actually
be counter productive if you were to immediately convert it to a
string. However, if you are moving data to some other binary
structure, it's a lot faster and less work for the server.
merlin