Resent-From: POSTGRES mailing list <postman@postgres.Berkeley.EDU>
Resent-Message-Id: <199403070246.SAA16021@nobozo.CS.Berkeley.EDU>
Sender: owner-postman@postgres.Berkeley.EDU
From: Aaron Roydhouse <Aaron.Roydhouse@Comp.VUW.AC.NZ>
Message-Id: <199403070245.PAA28503@downstage.comp.vuw.ac.nz>
To: postgres@postgres.Berkeley.EDU
Subject: Reading polygon fields from iportals
Date: Mon, 07 Mar 1994 15:45:52 +1300
Resent-To: postgres-dist@postgres.Berkeley.EDU
Resent-Date: Sun, 06 Mar 94 18:46:11 -0800
Resent-XMts: smtp

To avoid very expensive string <-> floating point conversions with
quite large polygons I have decided to use iportals and access results
in the implementation dependent format.

This has worked fine for the other types of fields (float8, bool,
char16, int4) but I have been unable to interpret what I am given for
the polygon type.

I believe there must be something I don't know about the way variable
length types work. I note that p.117 of the reference manual says
variable types don't include their size field (and are thus 4 bytes
shorter) but I also tired this and it doesn't make the polygon fields
any more intelligible.

Anyone know what I'm missing? If anyone has any chunks of code that
interprets a variable length postgres type from an iportal, I'd
appreciate it if you would send them to me.

I've included some more details of my confusion below.

Thanks,
Aaron.
--------------------
I'm using the type declared in geo-decls.h

typedef struct {
        long size;
        long npts;
        BOX boundbox;
        char pts[1];
} POLYGON;

on the result of PQgetvalue() or assuming the size field isn't there,
(PQgetvalue() - sizeof(long)).

PQgetlength returns just the size I would expect (sizeof(long) +
sizeof(long) + sizeof(BOX) + 2 * npts * sizeof(double)).

Despite this, I note that the size field contains exactly what I would
expect to find in the npts field, suggest the size field is indeed not
supplied. Yet everything there-after appears to be garbage.

I fiddled with the debugger but have been unable to find a valid
double anywhere in those bytes!

The same fields retrieve fine if I use portals rather than iportals.