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
tsearch2.sql.in.diff
Description: tsearch2.sql.in.diff
"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.
While I have no partic
> -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 instal
"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
> >> 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
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
>> Oh. Hmm ... wouldn't it be easier and safer to launch "psql > 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
Dear Magnus,
Oh. Hmm ... wouldn't it be easier and safer to launch "psql 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'
> -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 cu
Tom Lane wrote:
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
Oh. Hmm ... wouldn't it be easier and safer to launch "psql
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
> -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
"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
Dave Page wrote:
cube
seg
patch attached. Compiles, but not tested.
miscutil
Needs review; includes some deprecated stuff (backend_pid)
pg_logger
deprecated; use redirect_stderr (BTW, is it default on win32 now?)
pgcrypto
misses -lws2_32. According to README, it needs some tuning concerning
random
> -Original Message-
> From: Andreas Pflug [mailto:[EMAIL PROTECTED]
> Sent: 08 September 2004 19:15
> To: Dave Page
> Cc: PgSQL Win32 developers; PostgreSQL Patches
> Subject: Re: [pgsql-hackers-win32] Contrib modules on Win32
>
> Dave Page wrote:
> >
> > cube
> > seg
>
> patch atta
OK, I have applied the following patch to fix the Cygwin _timezone
issue. I moved the TIMEZONE_GLOBAL up into port.h and change pgtz.c to
use that instead. I also changed the configure test for INT_TIMEZONE to
test for _timezone on Cygwin. This should fix all those problems.
You found a few pr
Patchers,
Here is a simple patch that changes heap_modifytuple to require a
TupleDesc instead of a Relation (driven off a comment in the same
function). I didn't really look to see if anything can be simplified
because of this change.
All backend callers changed; there are no callers in contrib
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Here is a simple patch that changes heap_modifytuple to require a
> TupleDesc instead of a Relation (driven off a comment in the same
> function). I didn't really look to see if anything can be simplified
> because of this change.
I don't think that mi
I have done the same cleanup for _tzname for clarity and because some
files were using tzname as local variable names (pgtz.c).
---
Bruce Momjian wrote:
>
> OK, I have applied the following patch to fix the Cygwin _timezone
Win32 compile fixes for pgbench, pgcrypto, and tsearch.
Note: pgbench is the only one I actually use, and hence have tested
Cheers,
Claudio
---
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see
http://www.memetrics
Win32 compile fix for misc_utils.
Note: As before, un-tested.
---
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see
http://www.memetrics.com/emailpolicy.html";>http://www.memetrics.com/em
ailpolicy.html
misc_u
19 matches
Mail list logo
