Opened 14 years ago

Closed 14 years ago

#522 closed defect (invalid)

pgsql2shp ignoring the -f switch

Reported by: robe Owned by: pramsey
Priority: medium Milestone: PostGIS 1.5.2
Component: postgis Version: 1.5.X
Keywords: Cc:

Description

I used to be able to do this with older pgsql2shps

pgsql2shp -h prodserv -p 5434 -u robe gisdb vwprojects -f projects -g the_point

Now it outputs the file as vwprojects instead of the projects name I designate.

Change History (9)

comment:1 by mcayland, 14 years ago

Can you point towards a last-known good version?

comment:2 by robe, 14 years ago

I'm verifying the one I reverted to that I know doesn't have this problem is pgsql2shp.c 4870 2009-11-20 14:02:50Z mcayland $ RELEASE: 1.5

I know definitely the problem starts before

5181 2010-02-01 17:35:55Z pramsey $ RELEASE: 1.5

Since that one is bad.

comment:3 by robe, 14 years ago

So in short all our released versions of 1.5 are defective. I suspect this is related to the other issue I brought up with the shp2pgsql ignoring switches a bit before 1.5.0 release that we fixed - in #401 then again maybe not.

comment:4 by mcayland, 14 years ago

Ah. Didn't Paul change the getopt() stuff again a short time before release?

comment:5 by robe, 14 years ago

Milestone: PostGIS 1.5.2PostGIS 1.5.3

I checked and this is still a problem. Worsed yet if I do an adhoc query

pgsql2shp -h prodserv -p 5434 -u robe gisdb "SELECT * FROM vwdndprojects WHERE the_point IS NOT NULL" -f dndprojects -g the_point

I get the esri shape file named with the random temp table name created

e.g. pgsql2shp4524_tmp_table.dbf

I'm going to push this to 1.5.3 though. I don't feel its enough to hold up a release since it was broken in 1.5.1 as well. Like Devrim, I feel getting 1.5.2 out in time for PostgreSQL 9.0 inclusion is more important than fixing issues that were present in the last minor version. We can always make another release of 1.5.3 sooner than later.

comment:6 by mcayland, 14 years ago

Resolution: fixed
Status: newclosed

I don't think this is a bug. According to the pgsql2shp help output:

USAGE: ./pgsql2shp [<options>] <database> [<schema>.]<table>

./pgsql2shp [<options>] <database> <query>

Both the database and query/table arguments are compulsary and must be the last arguments (looking at the code, this restriction will have always existed unless system getopt()s have started doing something really clever before the switch back to our inbuilt one).

Variations on the following queries work for me on both Win32 and Linux:

pgsql2shp -h prodserv -p 5434 -u robe -f projects -g the_point gisdb vwprojects pgsql2shp -h prodserv -p 5434 -u robe -f dndprojects -g the_point gisdb "SELECT * FROM vwdndprojects WHERE the_point IS NOT NULL"

Regina, can you confirm and resolve as "invalid" if this works in your tests?

comment:7 by mcayland, 14 years ago

Resolution: fixed
Status: closedreopened

comment:8 by robe, 14 years ago

Okay I'll check next I get the chance. I can assure you though the syntax I posted above used to work. In fact all I have to do to get it to work is to revert the pgsql2shp (to I think early 1.5 or 1.4).

Though I guess you are right in theory it should never have worked though it did :).

comment:9 by robe, 14 years ago

Milestone: PostGIS 1.5.3PostGIS 1.5.2
Resolution: invalid
Status: reopenedclosed

okay seems to work in that order. I guess I'll just have to change all my code that uses the wrong order.

Note: See TracTickets for help on using tickets.