Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-general by date

Next:From: tglDate: 2004-07-27 01:18:10
Subject: Re: Mail Authentification
Previous:From: Tom LaneDate: 2004-07-27 01:09:12
Subject: Re: estimating table size

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group