From: | korry <korry(at)starband(dot)net> |
---|---|
To: | snpe <snpe(at)snpe(dot)co(dot)yu>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: protocol change in 7.4 |
Date: | 2002-11-07 21:50:00 |
Message-ID: | 5.1.0.14.0.20021107164245.043844c8@pop.starband.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > b) Send a decoded version of atttypmod - specifically, decode the
> > precision and scale for numeric types.
> >
>I want decode type,length,precision and scale
Type is returned by PQftype(), length is returned by PQfsize(). Precision
and scale are encoded in the return value from PQfmod() and you have to
have a magic decoder ring to understand them. (Magic decoder rings are
available, you just have to read the source code :-)
PQftype() is not easy to use because it returns an OID instead of a name
(or a standardized symbol), but I can't think of anything better to return
to the client. Of course if you really want to make use of PQftype(), you
can preload a client-side cache of type definitions. I seem to remember
seeing a patch a while back that would build the cache and decode precision
and scale too.
PQfsize() is entertaining, but not often what you really want (you really
want the width of the widest value in the column after conversion to some
string format - it seems reasonable to let the client applicatin worry
about that, although maybe that would be a useful client-side libpq function).
From | Date | Subject | |
---|---|---|---|
Next Message | Neil Conway | 2002-11-07 21:51:04 | Re: Outstanding patches |
Previous Message | Larry Rosenman | 2002-11-07 21:41:53 | Re: [HACKERS] PostgreSQL supported platform report and a |