[postgis-users] ESRI Shapes from database

[Chris Hermansen]

>From the "one last thought" department...

So in C#, you tried building a great big string containing a set of SQL
statements, which you were going to hand off to some kind of C# /
PostgreSQL interface.  The string got too big and it broke.

What is the nature of that C# interface?  Is it ODBC-like?  Or were you
just going to heave the string at psql embedded in some kind of "system"
call?  Pardon my ignorance of C# - PostgreSQL interfaces...

If the C# interface is ODBC like, can you not issue a bunch of method
calls, one for the CREATE TABLE, one for each INSERT INTO, one for the
index, etc.  Then your strings should be nice and short, and you can
conceal - to some degree at least - the user name and password within
the compiled code?

If that's not the case, what about writing the SQL out to a temporary
text file, or set of text files if length is an issue, and then either
using the "system" facility to call psql or writing a small Python
program that uses say psychopg to fire the data off into PostgreSQL? 
You can obscure the user name and password by compiling the Python.

Or you could write the whole thing in Python, which you should be able
to use to pull data out of the geodatabase as well as put data into
PostgreSQL.  Or maybe Java, JDBC allowing you the same ability to hide
user names and passwords within the compiled code.

Lee Keel wrote:
>> -----Original Message-----
>> From: postgis-users-bounces at postgis.refractions.net [mailto:postgis-users-
>> bounces at postgis.refractions.net] On Behalf Of Chris Hermansen
>> Sent: Tuesday, October 16, 2007 2:21 PM
>> To: PostGIS Users Discussion
>> Subject: Re: [postgis-users] ESRI Shapes from database
>>
>> Hmm, I think putting passwords on command lines in scripts kind of
>> invalidates the whole point of having passwords...
>>
>> Talking from a "this ought to be the way" point of view, rather than
>> "this is the way"... if user U is authenticated on machine X and your
>> authentication mechanism is robust then U should also be authenticated
>> on machine Y, so the only time a password should be needed is if U is
>> trying to masquerade as someone else.
>>
>> So if user U's credentials are respected on your PostgreSQL server and
>> if there is a role defined for user U in the PostgreSQL instance running
>> on the server, then s/he should be able to execute psql on that server
>> just by running
>>    psql -h post-server database-name -f script.sql
>>
>> ¿no?
>>
>>     
>
> I don't have a problem with all that, I just don't know if they will buy
> into it.  I am going to present this exact email to my client and see if
> they will agree.
>
> Thanks for all the help.
> LK
>
> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>   


-- 
Regards,

Chris Hermansen · mailto:clh at timberline.ca
tel:+1.604.714.2878 · fax:+1.604.733.0631
Timberline Natural Resource Group · http://www.timberline.ca
401 · 958 West 8th Avenue · Vancouver BC · Canada · V5Z 1E5

C'est ma façon de parler.