Re: parsing binary varchar[]-s

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Igor Shevchenko <igor(at)carcass(dot)ath(dot)cx>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: parsing binary varchar[]-s
Date: 2004-07-27 01:17:03
Message-ID: 15573.1090891023@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Igor Shevchenko <igor(at)carcass(dot)ath(dot)cx> writes:
> I use binary mode for sending params and receiving data using libpq with
> protocol v3; PostgreSQL version is 7.4.3.
> Here, varchar[]-s are returned in binary mode; they're generated from internal
> structs by "array_send" function in src/backend/utils/adt/arrayfuncs.c.
> PQftype(..) returns 1015 for those columns. I couldn't find any #define for
> this OID -- does this mean it can change in future pg releases ?

It's "_varchar" in pg_type.h, and no the OID is not likely to change.
(Any OID under 10000 is manually assigned and we would have to go out
of our way to change it.)

> Also, can I safely use the binary format as described (by the code) in
> "array_send" ? Is this interface is frozen, as a part of protocol v3
> spec ?

Yes, the intention is that those formats are frozen. We haven't gotten
around to collecting the information in a document, so you have to look
at the code, but it's supposed to not change.

At least up to a point ;-). Sooner or later we are going to want to
support null elements within arrays, and that will surely impact the
internal format as well as the transmitted format. My guess is that
arrays that do not contain any nulls will look the same as now, but
if there are nulls then a bit will be set in the flags word and we'll
insert a null bitmap someplace. So I'd strongly recommend checking the
flags word and punting if it contains a value you do not recognize.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message tgl 2004-07-27 01:18:10 Re: Mail Authentification
Previous Message Tom Lane 2004-07-27 01:09:12 Re: estimating table size