[fdo-internals] Defects in PostGIS provider

Chuck Wilbur chuckwilbur at spatialnet.net
Wed Aug 22 16:44:43 EDT 2007


> The provider generates WKB stream from FDO geometry and inserts it
> directly into INSERT INTO statement.

Right, I see that in the code, and it fails for geometry. For the sample
"Blue Lake" polygon geometry from the FDO documentation, PostGIS returns
(through the provider):
NOTICE:  identifier "a400000000000003240000
00000008050400000000000003740000000000040524000000000000022400000000000004840000
00000000018400000000000004a400000000000003240050000000000000000804d4000000000000
032400000000000c0504000000000000032400000000000c050400000000000002a4000000000008
04d400000000000002a400000000000804d400000000000003240" will be truncated to
"a40
000000000000324000000000008050400000000000003740000000000040"

The execution of SQL statement failed with PostgreSQL error
 code: PGRES_FATAL_ERROR, ERROR:  syntax error at or near
"A40000000000000324000
00000000805040000000000000374000000000004052400000000000002240000000000000484000
000000000018400000000000004A400000000000003240050000000000000000804D400000000000
0032400000000000C0504000000000000032400000000000C050400000000000002A400000000000
804D400000000000002A400000000000804D400000000000003240"
LINE 1: ...Blue Lake',010300000002000000050000000000000000004A400000000...
                                                             ^
> Does it crash for every geometry or may be if you use XYZ or XYZM
> dimensions?

The geometries I've tested with are simple XY-only. A simple geometry like a
point doesn't get the "identifier truncated" message, but it still fails
with the syntax error because (I think) PostGIS is trying to interpret the
long binary hexadecimal number as a long decimal integer.

I would think that to fix this you would need to either get the stream as
text and use GeomFromText in the statement or use fully parameterized
queries into PostGIS. The second would almost certainly be the better
solution, but I don't know the syntax or API for parameterized queries in
PostGIS, especially when one of the parameters is a WKB geometry. I would
have to do some research.

>> 2) ApplySchemaCommand::Execute always issues CREATE TABLE statement(s) -
>> it
>> cannot be used to delete a feature class.
> Hmm, I'm not sure I understand.
> ApplySchema command is not used for removing feature classes (tables).

In other providers it is. Using an FdoFeatureSchema pSchema from the
connection's schema collection:

// remove the class from the schema
FdoPtr<FdoClassCollection> pClassColl = pSchema->GetClasses();
FdoPtr<FdoClassDefinition> pClass =
	pClassColl->FindItem(strFullClassName);
if ( pClass )
{
	pClass->Delete();

	// Create the ApplySchema command
	FdoPtr<FdoIApplySchema> pApplySchemaCmd = dynamic_cast<FdoIApplySchema*>(
		m_connection->CreateCommand(FdoCommandType_ApplySchema) );

	// Set the schema and execute the apply schema command
	pApplySchemaCmd->SetFeatureSchema(pSchema);
	pApplySchemaCmd->Execute();
}

The code above is a simplified version of what I've used with other
providers to drop feature classes. This is important functionality for my
unit tests to ensure that I'm starting with a clean table each run.
-- 
View this message in context: http://www.nabble.com/Defects-in-PostGIS-provider-tf4313206s18162.html#a12282593
Sent from the fdo-internals mailing list archive at Nabble.com.



More information about the fdo-internals mailing list