Re: [PATCHES] Tsearch2 update for Win32.
-Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: 14 September 2004 05:00 To: Dave Page Cc: PostgreSQL-patches Subject: Re: [PATCHES] Tsearch2 update for Win32. Dave Page [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] Tsearch2 update for Win32.
Dave Page [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] Tsearch2 update for Win32.
-Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] 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. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] Tsearch2 update for Win32.
Dave Page [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
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. 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 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] Tsearch2 update for Win32.
Magnus Hagander [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] Tsearch2 update for Win32.
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. ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] Tsearch2 update for Win32.
-Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] 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. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] Tsearch2 update for Win32.
Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] Tsearch2 update for Win32.
-Original Message- From: Andrew Dunstan [mailto:[EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] Tsearch2 update for Win32.
Dave Page [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
