Thread: Tsearch2 update for Win32.
The Win32 installer cannot easily handle 'copy from stdin' thus preventing execution of scripts that use copy. Tsearch2 appears to have the only script that does this - the attached patch changes the copy to a bunch of INSERTs. Regards, Dave
Attachment
"Dave Page" <dpage@vale-housing.co.uk> writes:
> The Win32 installer cannot easily handle 'copy from stdin' thus
> preventing execution of scripts that use copy. Tsearch2 appears to have
> the only script that does this - the attached patch changes the copy to
> a bunch of INSERTs.
While I have no particular objection to adjusting the tsearch2 script,
why has the installer got a problem with it? Seems like this suggests
a bug in win32 psql. (I'm not sure why the installer would even be
executing this script anyway ...)
regards, tom lane
> -----Original Message----- > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > Sent: 08 September 2004 15:14 > To: Dave Page > Cc: PostgreSQL-patches > Subject: Re: [PATCHES] Tsearch2 update for Win32. > > While I have no particular objection to adjusting the > tsearch2 script, why has the installer got a problem with it? > Seems like this suggests a bug in win32 psql. The installer runs contrib module scripts without using psql - it executes them in a 'custom action' - code that is added to the installation package in this case as a dll. Adding copy support for one contrib module is a headache I'd prefer to avoid :-) > (I'm not sure > why the installer would even be executing this script anyway ...) It's a point and click (drool?) installer - it installs pg along with pgAdmin and interfaces such as JDBC, Npgsql and psqlODBC, creates the service user account, initdb's, installs any PLs and contrib modules the user has selected. The user doesn't need to use psql at all if he doesn't wish - which is exactly what most SQL Server/Windows users are used to; no command line tools. Regards, Dave.
"Dave Page" <dpage@vale-housing.co.uk> writes:
>> While I have no particular objection to adjusting the
>> tsearch2 script, why has the installer got a problem with it?
>> Seems like this suggests a bug in win32 psql.
> The installer runs contrib module scripts without using psql - it
> executes them in a 'custom action' - code that is added to the
> installation package in this case as a dll.
Oh. Hmm ... wouldn't it be easier and safer to launch "psql <script"
as a subprocess?
regards, tom lane
> >> While I have no particular objection to adjusting the > >> tsearch2 script, why has the installer got a problem with it? > >> Seems like this suggests a bug in win32 psql. > > > The installer runs contrib module scripts without using psql - it > > executes them in a 'custom action' - code that is added to the > > installation package in this case as a dll. > > Oh. Hmm ... wouldn't it be easier and safer to launch "psql <script" > as a subprocess? I'd say no. Executing processes from the installer environment can be a headache (we've had enough problems with initdb already..). And you have to go through all the weirdness with the commandline quoting etc on win32... It's a lot easier to execute a SQL script line-by-line. Which also lets us trap the errors easier etc. //Magnus
"Magnus Hagander" <mha@sollentuna.net> writes:
>> Oh. Hmm ... wouldn't it be easier and safer to launch "psql <script"
>> as a subprocess?
> I'd say no. Executing processes from the installer environment can be a
> headache (we've had enough problems with initdb already..). And you have
> to go through all the weirdness with the commandline quoting etc on
> win32... It's a lot easier to execute a SQL script line-by-line. Which
> also lets us trap the errors easier etc.
I was about to mention trapping errors as being a likely weak spot of
custom-script-execution code. And have you duplicated psql's rather
extensive logic for determining where SQL commands end? I'll get a bit
annoyed if you come back later and tell us not to use dollar quoting
in contrib scripts, or something like that.
However, the COPY->INSERT change alone is below my threshold of pain,
so I won't complain too hard. I just wanted to be sure you'd really
thought about the implications of rolling your own script executor.
regards, tom lane
Dear Magnus, >> Oh. Hmm ... wouldn't it be easier and safer to launch "psql <script" >> as a subprocess? > > I'd say no. Executing processes from the installer environment can be a > headache (we've had enough problems with initdb already..). And you have > to go through all the weirdness with the commandline quoting etc on > win32... It's a lot easier to execute a SQL script line-by-line. Which > also lets us trap the errors easier etc. Maybe you're suggesting that psql and other commands functionnalities should be made into some kind of a dynamic library to be loaded and called from the installer, if using an external program is so difficult on win32? I used to think that windows was posix somehow, so that it should provide some 'exec*' functions which do not rely on shell scripting and should not require much quoting. Partially replicating functionnalities and adding bugs or limitations to them does not seem so good a idea from a software engineering perspective. Well, just my 0.02 EUR. I think it is a good thing that pg is available on windows, so thanks for that anyway! Have a nice day, -- Fabien.
> -----Original Message----- > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > Sent: 08 September 2004 15:49 > To: Magnus Hagander > Cc: Dave Page; PostgreSQL-patches > Subject: Re: [PATCHES] Tsearch2 update for Win32. > > I was about to mention trapping errors as being a likely weak > spot of custom-script-execution code. And have you > duplicated psql's rather extensive logic for determining > where SQL commands end? No. Currently it just feeds the scripts into PQexec in one go with no parsing. There's a fair bit of work to do as well as this so we're crossing bridges as we get to them, And as there aren't any contribs with $ quoting yet (that I've found so far anyway)... Anyway, no need to get annoyed - if it were more than a few inserts in one file, I would be looking to enhance our code; I've no wish to make the core distro any less maintainable.readable/whatever. Regards, Dave.
Tom Lane wrote: >"Magnus Hagander" <mha@sollentuna.net> writes: > > >>>Oh. Hmm ... wouldn't it be easier and safer to launch "psql <script" >>>as a subprocess? >>> >>> > > > >>I'd say no. Executing processes from the installer environment can be a >>headache (we've had enough problems with initdb already..). And you have >>to go through all the weirdness with the commandline quoting etc on >>win32... It's a lot easier to execute a SQL script line-by-line. Which >>also lets us trap the errors easier etc. >> >> > >I was about to mention trapping errors as being a likely weak spot of >custom-script-execution code. And have you duplicated psql's rather >extensive logic for determining where SQL commands end? I'll get a bit >annoyed if you come back later and tell us not to use dollar quoting >in contrib scripts, or something like that. > >However, the COPY->INSERT change alone is below my threshold of pain, >so I won't complain too hard. I just wanted to be sure you'd really >thought about the implications of rolling your own script executor. > > > > Not to mention someone putting a \ command in the install script. I understand the difficulties, but ISTM that getting "psql -f scriptfile" working could be a Good Thing (tm). OTOH, should the installer be running the contrib install scripts, or should this be left as a job for the administrator? Maybe we're trying to do too much. cheers andrew
> -----Original Message----- > From: Andrew Dunstan [mailto:andrew@dunslane.net] > Sent: 08 September 2004 17:17 > To: Tom Lane > Cc: Magnus Hagander; Dave Page; PostgreSQL-patches > Subject: Re: [PATCHES] Tsearch2 update for Win32. > > > Not to mention someone putting a \ command in the install > script. I understand the difficulties, but ISTM that getting > "psql -f scriptfile" > working could be a Good Thing (tm). If you have any suggestions on how we can trap errors I'm all ears (well, eyes) :-) > OTOH, should the > installer be running the contrib install scripts, or should > this be left as a job for the administrator? Maybe we're > trying to do too much. This is Windows and users will not expect to have to use command line tools - and pgAdmin suffers the same problem as the installer - it cannot handle \ commands etc. either. Regards, Dave
"Dave Page" <dpage@vale-housing.co.uk> writes:
>> I understand the difficulties, but ISTM that getting
>> "psql -f scriptfile"
>> working could be a Good Thing (tm).
> If you have any suggestions on how we can trap errors I'm all ears
I believe you can look at psql's exit status. (You may need to do
something to ensure it exits on first error, too.)
However the existing solution is probably good enough for now.
regards, tom lane
"Dave Page" <dpage@vale-housing.co.uk> writes:
> The Win32 installer cannot easily handle 'copy from stdin' thus
> preventing execution of scripts that use copy. Tsearch2 appears to have
> the only script that does this - the attached patch changes the copy to
> a bunch of INSERTs.
Applied. I also fixed the regression test to match (tsk tsk)
regards, tom lane
> -----Original Message----- > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > Sent: 14 September 2004 05:00 > To: Dave Page > Cc: PostgreSQL-patches > Subject: Re: [PATCHES] Tsearch2 update for Win32. > > "Dave Page" <dpage@vale-housing.co.uk> writes: > > The Win32 installer cannot easily handle 'copy from stdin' thus > > preventing execution of scripts that use copy. Tsearch2 appears to > > have the only script that does this - the attached patch > changes the > > copy to a bunch of INSERTs. > > Applied. I also fixed the regression test to match (tsk tsk) Ooops, sorry - didn't realise there was one. Regards, Dave