[fdo-trac] #394: PostGIS Defect : Describe schema fails when advanced types present

[FDO]

#394: PostGIS Defect : Describe schema fails when advanced types present
------------------------------+---------------------------------------------
 Reporter:  mwtoews           |         Owner:  mloskot
     Type:  defect            |        Status:  new    
 Priority:  critical          |     Milestone:         
Component:  PostGIS Provider  |       Version:  3.2.3  
 Severity:  2                 |    Resolution:         
 Keywords:                    |   External_id:         
------------------------------+---------------------------------------------
Comment (by mwtoews):

 I wasn't suggesting that FDO needs to support advanced types, since these
 often get complicated with PostgreSQL (custom types are easy to build).
 Rather, I'm suggesting better support/fallback when they are present.

 The suggestion I'm trying to illustrate on PostgreSQL<->FDO communication
 is:
  * PG->FDO: unsupported PG types are cast to text for FDO (e.g.,
 myarray::text)
  * FDO->PG: the text from FDO is cast back to the unsupported PG type
 (e.g., "{1,2,3}"::int[])

 This is nicely and seamlessly implemented in the psqlODBC driver, and I
 have absolutely no problems seeing and editing all my tables with
 "advanced types" in MS Access. I think all PG types (including custom and
 extension types) support bidirectional customtype<->text casts, so you
 could offload all type conversions to PG without much effort from FDO. All
 that needs to be done by FDO is to manage the casting to/from text for
 unsupported types on insert/select/update operations.

-- 
Ticket URL: <http://trac.osgeo.org/fdo/ticket/394#comment:3>
FDO <http://fdo.osgeo.org/>
Feature Data Objects