[postgis-devel] loader incompatibility

[strk at refractions.net]

On Fri, Apr 01, 2005 at 10:11:16AM +0100, Mark Cave-Ayland wrote:
> Hi strk,
> 
> > -----Original Message-----
> > From: postgis-devel-bounces at postgis.refractions.net 
> > [mailto:postgis-devel-bounces at postgis.refractions.net] On 
> > Behalf Of strk at refractions.net
> > Sent: 01 April 2005 08:59
> > To: postgis-devel at postgis.refractions.net
> > Subject: [postgis-devel] loader incompatibility
> > 
> > 
> > Yes, it is again too late for this, but before we
> > release 1.0.0, should we somehow handle the incompatibilities 
> > between 0.x and 1.x loader ?
> > 
> > The new shp2pgsql will produce HEXEWKB queries.
> > The old shp2pgsql will produce GeometryFromText(EWKT) queries.
> > 
> > The old shp2pgsql will work against new postgis.
> > The new shp2pgsql will NOT work against old postgis.
> 
>           ^^^^^^^^^
> 
> I guess you meant to type pgsql2shp? ;)

Nope. I meant shp2pgsql.
pgsql2shp works on every postgis version as it talks to the database
thus it is able to extract postgis version before proceding.

> > I asked before, in the last mail of a long solo thread: 
> >
> http://postgis.refractions.net/pipermail/postgis-devel/2004-October/000537.h
> tml

  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This explains the problem.

> > My current concern is: is people have both 0.x and 1.x 
> > postgis installed they need both 0.x and 1.x loader too,
> > while current installation rule would make one override
> > the other.
> 
> I must say I don't see this as much of as issue. Since the major number has
> been bumped, people expect 1.0 to be different to 0.9.x, so my personal
> expectation would be to have to re-generate new SQL from my original
> shapefiles and reload them into the database, which is not particularly
> difficult. For people who want to upgrade from 0.9.x to 1.0 then they can
> just dump and then reload if they've already loaded their shapefiles without
> touching shp2pgsql/pgsql2shp....

Fair enough. Your opinion lowers my paranoia level ;)

> Looks at the source... I see in pgsql2shp that the main loop declares a
> cursor and then does a "FETCH %d FROM cur", where %d is rowbuflen which
> defaults to 100. As far as I can see, this FETCH is only called once and so
> the resulting shapefile will be truncated to 100 records maximum - or are my
> eyes deceiving me?

Execution of that FETCH query is inside a while(1) loop (264).
The loop is explicitly broke by an empty result set.
You can trmodify rowbuflen with an environmental variable (undocumented):

ROWBUFLEN=1000 pgsql2shp db table
ROWBUFLEN=100 pgsql2shp db table
ROWBUFLEN=10 pgsql2shp db table
ROWBUFLEN=1 pgsql2shp db table

--strk;