[fdo-internals] xmin and xmax are reserved keywords

[Paul Ramsey]

It does but the xmin and xmax are more than reserved words, they are  
actually special hidden columns (like oid) that actually occur in  
every table.  So it's not possible to use them as column names at  
all, double quoted, in camel case, or otherwise.

On 15-Jan-07, at 5:27 AM, Brent Robinson wrote:

> 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
> _______________________________________________
> fdo-internals mailing list
> fdo-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/fdo-internals