[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