[fdo-internals] xmin and xmax are reserved keywords

[Brent Robinson]

Hi Mateusz,

Does PostGIS support double quote delimiting for table and column names
in select statements?

If it does then another option might be to double-quote delimit these
names in the select statements issued by the Schema Manager. This would
be a fairly small change to utilities/SchemaMgr/src/Ph/Field.cpp.

The GenericRdbms feature command implementations already do quote
delimiting for the SQL that they generated so it would be good to do
this in the Schema Manager as well.

Brent.


-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Mateusz
Loskot
Sent: Sunday, January 14, 2007 1:15 PM
To: fdo-internals at lists.osgeo.org
Cc: fdo_dev at lists.osgeo.org; Jason Birch
Subject: [fdo-internals] xmin and xmax are reserved keywords

Hi,

For a few recent days, I've been trying to find out how to override
default behavior (implementation) of classes relates to SpatialContext,
SpatialContextGeomReader/Writer, SpatialContextGroupReader/Writer,
SpatialContextCollection.

The reason is that these classes use hardcoded column names
which are reserved keywords in PostgreSQL, like xmin, xmax.
Here is the list:

http://www.postgresql.org/docs/8.2/interactive/ddl-system-columns.html

Now, the only solution I can see is to rename these columns
in the FDO Core's Schema Manger types for spatial context management.
Even though, I understand how it influences the rest of FDO components,
I don't see how could I solve it better.
Unfortunately, there is no way to make these names not reserved
words on PostgreSQL side.

Do you think it's possible to solve this problem and use different
column names for PostgreSQL/PostGIS provider only?

If there isn't any such solution, I'd like to call for motion to rename
these columns to something safer - for instance, with fdo_ prefix.


As I see in the King Oracle provider, the problem is solved differently.
The King Oracle provides its own implementation, completely unrelated to
Generic RDBMS or even to Schema Manger in FDO Core utilities.

Higher abstractions of FDO just are get ready to use spatial context and
spatial context reader objects implementing FDO API.

Unfortunately, this is not an option for me - not counting complete
rewrite of my provider in the same way the King Oracle is implemented
(may be if I'd have a free month I could do it :-) )

Please, I'd be very thankful for a piece of advice how to solve my
problems, because it has stopped me completely now.

Cheers

p.s. I'm posting this message to both addresses:
the new - fdo-internals at lists.osgeo.org,
and the old - fdo_dev at lists.osgeo.org (just to be sure it will arrive),
only this time. Next messages will go to the new address.

-- 
Mateusz Loskot
http://mateusz.loskot.net
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals