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

Re: Bad behaviour when inserting unspecified variable length

From: Dave Blasby <dblasby(at)refractions(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Bad behaviour when inserting unspecified variable length
Date: 2001-09-04 17:16:20
Message-ID: 3B950C64.22048603@refractions.net (view raw or flat)
Thread:
Lists: pgsql-hackers
> Uh, what did your CREATE TYPE command look like, exactly?  This sounds
> like you specified a default value for the datatype.

Okay, here's two examples;

CREATE TYPE WKB (
	internallength = VARIABLE,
	input =  WKB_in,
	output =  WKB_out,
	storage= extended
);


CREATE TYPE GEOMETRY (
	alignment = double,
	internallength = VARIABLE,
	input =  geometry_in,
	output =  geometry_out,
	storage = main
);


I've tried the WKB type with a "DEFAULT = NULL" clause and all the
different storage types.  The same problem occurs everytime.

Here's the create function statements for the _in and _out functions;

create function WKB_in(opaque)
	RETURNS WKB
   AS '@MODULE_FILENAME@','WKB_in'
   LANGUAGE 'c' with (isstrict);

create function WKB_out(opaque)
	RETURNS opaque
   AS '@MODULE_FILENAME@','WKB_out'
   LANGUAGE 'c' with (isstrict);

create function geometry_in(opaque)
	RETURNS GEOMETRY
   AS '@MODULE_FILENAME@'
   LANGUAGE 'c' with (isstrict);

create function geometry_out(opaque)
	RETURNS opaque
   AS '@MODULE_FILENAME@'
   LANGUAGE 'c' with (isstrict);



> Maybe you need to show us your datatype's I/O functions, too.

I dont thing they're important.  WKB_in and geometry_in are *never*
called, and WKB_out and geometry_out are called with bad values.  Only
one line of my code is executed in the _out functions.  

	WellKnownBinary		      *WKB = (WellKnownBinary *) 
PG_DETOAST_DATUM(PG_GETARG_DATUM(0));

		or

	GEOMETRY		   *geom1 = (GEOMETRY *) 
PG_DETOAST_DATUM(PG_GETARG_DATUM(0));

(See below for a simpler example)

> Since
> this works perfectly fine for the standard variable-length datatypes,

Yes, on system (7.1.2 under solaris) the following works;
 create table ttt (i integer, mytext text);
 insert into ttt values (1);
 select * from ttt;
 i | mytext 
---+----
 1 | 
(1 row)


Here's the simplest example I can come up with to show the problem;

create function WKB_in2(opaque)
        RETURNS WKB
   AS
'/data1/Refractions/Projects/PostGIS/work_dave/postgis/libpostgis.so.0.5','WKB_in2'
   LANGUAGE 'c' with (isstrict);

create function WKB_out2(opaque)
        RETURNS opaque
   AS
'/data1/Refractions/Projects/PostGIS/work_dave/postgis/libpostgis.so.0.5','WKB_out2'
   LANGUAGE 'c' with (isstrict);


CREATE TYPE WKB (
        internallength = VARIABLE,
        input =  WKB_in2,
        output =  WKB_out2,
        storage= extended
);


dave=#  create table m (i integer, mywkb wkb);
dave=#  insert into m values (1);
dave=#  select * from m;
 i | mywkb 
---+-------
 1 | me
(1 row)


You'll also get this output from the printf in WKB_out (ASCII 45 is the
"-" char);
WKB_out2: WKB has length 5 and 1st value 45


typedef struct Well_known_bin {
	int32 size;    // total size of this structure
	unsigned char  data[1]; //THIS HOLDS VARIABLE LENGTH DATA
} WellKnownBinary;



PG_FUNCTION_INFO_V1(WKB_in2);
Datum WKB_in2(PG_FUNCTION_ARGS)
{
	char	   		*str = PG_GETARG_CSTRING(0);
	
	printf("I never get here!\n");

	PG_RETURN_NULL();
}

PG_FUNCTION_INFO_V1(WKB_out2);
Datum WKB_out2(PG_FUNCTION_ARGS)
{
	WellKnownBinary		      *WKB = (WellKnownBinary *) 
PG_DETOAST_DATUM(PG_GETARG_DATUM(0));
	char					*result;

	printf("WKB_out2: WKB has length %i and 1st value %i\n", WKB->size, 
(int) ((char *)WKB)[4] );

	// return something

	result = palloc(3);
	result[0] = 'm';
	result[1] = 'e';
	result[2] = 0;

	PG_RETURN_CSTRING(result);
}

In response to

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2001-09-04 17:30:54
Subject: Re: Escaping strings for inclusion into SQL queries
Previous:From: Larry RosenmanDate: 2001-09-04 17:13:00
Subject: Re: Bytea/Base64 encoders for libpq - interested?

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