[postgis-devel] SVN trunk parser modifications stage 2

David Fuhry dfuhry at acm.org
Mon Oct 27 12:22:41 PDT 2008


Regina,

Obe, Regina wrote:
> David,
>  > One problem with all of the function-overloading ideas, is that if you
>  > backup your geometries using pg_dump (COPY or INSERT mode), you won't
>  > necessarily be able to reimport them.  (Without using INSERT mode and
>  > writing an ugly script to wrap geometry fields in the loose parsing
>  > function.)
> 
> I don't quite understand this argument above.  Presumably copy and insert
> would be using the
> 
> CAST(...) syntax implicitly or just doing  memory copy so how would 
> overloading
> these functions cause problems?  The current ones would just not do any 
> checking which is desired since even if your data is no good, I presume 
> you still
> want to bring it in and deal with it inside the db.

COPY and INSERT reparse the geometry from EWKB.  If the parser cannot 
parse degenerate geometries (that is, if ST_GeomFromTextWithStrict() is 
the only way to load them), then it won't be possible to reload a 
degenerate geometry without modifying the dumpfile.  (The situation may 
be different with nonstandard  pg_dump --format=c or --format=t, I'm not 
sure.)

$ psql
db => create table tt as select 1, 'POINT(1 2)'::geometry;
db => insert into tt select 2, 'POINT(3 4)'::geometry;

$ pg_dump -t tt db
...
COPY tt ("?column?", geometry) FROM stdin;
1	0101000000000000000000F03F0000000000000040
2	010100000000000000000008400000000000001040
\.
...

$ pg_dump --inserts -t tt -a db
...
INSERT INTO tt VALUES (1, '0101000000000000000000F03F0000000000000040');
INSERT INTO tt VALUES (2, '010100000000000000000008400000000000001040');
...



More information about the postgis-devel mailing list