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

Re: Inserting data a UDT in binary format using LIBPQ

From: "Brijesh Shrivastav" <Bshrivastav(at)esri(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-interfaces(at)postgresql(dot)org>
Subject: Re: Inserting data a UDT in binary format using LIBPQ
Date: 2007-01-09 21:51:01
Message-ID: 5774D66D5EC83645A99B3A905527BB71B2A928@zipwire.esri.com (view raw or flat)
Thread:
Lists: pgsql-interfaces
FUNC_BINARY_FORMAT was similar to varlena struct and I thought
this is what you would get back from a detoasted argument in
recieve function but I guess it was a wrong assumption. I will
try StringInfo structure instead.

Thanks for the pointer.
Brijesh

> -----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
> Sent: Tuesday, January 09, 2007 1:17 PM
> To: Brijesh Shrivastav
> Cc: pgsql-interfaces(at)postgresql(dot)org
> Subject: Re: [INTERFACES] Inserting data a UDT in binary format using
> LIBPQ 
> 
> 
> "Brijesh Shrivastav" <Bshrivastav(at)esri(dot)com> writes:
> > Datum func_Recv(PG_FUNCTION_ARGS)
> > {
> >  	FUNC_BINARY_FORMAT *input 
> > 		= (FUNC_BINARY_FORMAT 
> *)PG_DETOAST_DATUM(PG_GETARG_DATUM(0));
> 
> Why would you expect that the input to a receive function would be
> already in the datatype's internal format?
> 
> I'm too lazy to go check the code right now, but my 
> recollection is that
> what you get is a reference to a StringInfo holding the data message
> received from the client.  You should probably not touch the 
> StringInfo
> directly if you can avoid it, but use the convenience 
> functions that are
> provided for receive functions to use.  Look at the code for existing
> receive functions for datatypes similar to yours.
> 
> 			regards, tom lane
> 
> 

pgsql-interfaces by date

Next:From: L BayukDate: 2007-01-10 00:41:00
Subject: Re: BCC55 and libpq 8.2
Previous:From: Tom LaneDate: 2007-01-09 21:17:20
Subject: Re: Inserting data a UDT in binary format using LIBPQ

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