[PATCHES] 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 tsearch2.sql.in.diff Description: tsearch2.sql.in.diff ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
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. 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 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
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
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 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 > 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 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 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
Re: [PATCHES] [pgsql-hackers-win32] Contrib modules on Win32
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() before deploying.
Regards,
Andreas
Index: cube.c
===
RCS file: /projects/cvsroot/pgsql-server/contrib/cube/cube.c,v
retrieving revision 1.16
diff -u -r1.16 cube.c
--- cube.c 29 Aug 2004 05:06:34 - 1.16
+++ cube.c 8 Sep 2004 17:45:32 -
@@ -15,8 +15,12 @@
#include "cubedata.h"
+#ifndef max
#define max(a,b) ((a) > (b) ? (a) : (b))
+#endif
+#ifndef min
#define min(a,b) ((a) <= (b) ? (a) : (b))
+#endif
#define abs(a) ((a) < (0) ? (-a) : (a))
extern int cube_yyparse();
Index: cubeparse.y
===
RCS file: /projects/cvsroot/pgsql-server/contrib/cube/cubeparse.y,v
retrieving revision 1.11
diff -u -r1.11 cubeparse.y
--- cubeparse.y 2 Sep 2004 20:53:42 - 1.11
+++ cubeparse.y 8 Sep 2004 17:45:43 -
@@ -28,7 +28,7 @@
%}
/* BISON Declarations */
-%token FLOAT O_PAREN C_PAREN O_BRACKET C_BRACKET COMMA
+%token CUBEFLOAT O_PAREN C_PAREN O_BRACKET C_BRACKET COMMA
%start box
/* Grammar follows */
@@ -128,13 +128,13 @@
;
list:
- FLOAT {
+ CUBEFLOAT {
/* alloc enough space to be sure whole list will fit */
$$ = palloc(scanbuflen + 1);
strcpy($$, $1);
}
|
- list COMMA FLOAT {
+ list COMMA CUBEFLOAT {
$$ = $1;
strcat($$, ",");
strcat($$, $3);
Index: cubescan.l
===
RCS file: /projects/cvsroot/pgsql-server/contrib/cube/cubescan.l,v
retrieving revision 1.8
diff -u -r1.8 cubescan.l
--- cubescan.l 24 Feb 2004 22:06:32 - 1.8
+++ cubescan.l 8 Sep 2004 17:45:50 -
@@ -39,7 +39,7 @@
%%
-{float} yylval = yytext; return FLOAT;
+{float} yylval = yytext; return CUBEFLOAT;
\[ yylval = "("; return O_BRACKET;
\] yylval = ")"; return C_BRACKET;
\( yylval = "("; return O_PAREN;
Index: seg.c
===
RCS file: /projects/cvsroot/pgsql-server/contrib/seg/seg.c,v
retrieving revision 1.10
diff -u -r1.10 seg.c
--- seg.c 29 Aug 2004 05:06:38 - 1.10
+++ seg.c 8 Sep 2004 17:58:00 -
@@ -14,8 +14,12 @@
#include "segdata.h"
+#ifndef max
#define max(a,b) ((a) > (b) ? (a) : (b))
+#endif
+#ifndef min
#define min(a,b) ((a) <= (b) ? (a) : (b))
+#endif
#define abs(a) ((a) < (0) ? (-a) : (a))
/*
@@ -946,7 +950,7 @@
if (exp == 0)
{
/* use the supplied mantyssa with sign */
- strcpy((char *) index(result, 'e'), "");
+ strcpy((char *) strchr(result, 'e'), "");
}
else
{
Index: segscan.l
===
RCS file: /projects/cvsroot/pgsql-server/contrib/seg/segscan.l,v
retrieving revision 1.7
diff -u -r1.7 segscan.l
--- segscan.l 24 Feb 2004 22:06:32 - 1.7
+++ segscan.l 8 Sep 2004 17:58:20 -
@@ -41,7 +41,7 @@
{range} yylval.text = yytext; return RANGE;
{plumin} yylval.text = yytext; return PLUMIN;
-{float} yylval.text = yytext; return FLOAT;
+{float} yylval.text = yytext; return SEGFLOAT;
\< yylval.text = "<"; return EXTENSION;
\> yylval.text = ">"; return EXTENSION;
\~ yylval.text = "~"; return EXTENSION;
Index: segparse.y
===
RCS file: /projects/cvsroot/pgsql-server/contrib/seg/segparse.y,v
retrieving revision 1.12
diff -u -r1.12 segparse.y
--- segparse.y 2 Sep 2004 20:53:42 - 1.12
+++ segparse.y 8 Sep 2004 17:59:28 -
@@ -38,7 +38,7 @@
} bnd;
char * text;
}
-%token FLOAT
+%token SEGFLOAT
%token RANGE
%token PLUMIN
%token EXTENSION
@@ -105,13 +105,13 @@
;
boundary:
- FLOAT {
+ SEGFLOAT {
$$.ext = '\0';
$$.sigd = significant_digits($1);
$$.val = seg_atof($1);
}
|
- EXTENSION FLOAT {
+ EXTENSION SEGFLOAT {
$$.ext = $1[0];
$$.sigd = significant_digits($2);
$$.val = seg_atof($2);
@@ -119,7 +119,7 @@
;
deviation:
- FLOAT {
+ SEGFLOAT {
$$.ext = '\0';
$$.sigd = significant_digits($1);
$$.val = seg_atof($1);
* CVS exited normally with code 1 *
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] [pgsql-hackers-win32] Contrib modules on Win32
> -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 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?) Yes, it's the default on Win32 (installer releases anyhoo). I take it this should be removed from /contrib then. > > pgcrypto > misses -lws2_32. According to README, it needs some tuning concerning > random() before deploying. I must have missed that - I've been using it in production on Linux for years... Regards, Dave. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] time_t timezone
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 problems in dirmod.c but have run out of time and will
deal with them in a few days.
---
Reini Urban wrote:
> Bruce Momjian schrieb:
>
> > Reini Urban wrote:
> >
> >>> # PGAC_VAR_INT_TIMEZONE
> >>> # -
> >>> # Check if the global variable `timezone' exists. If so, define
> >>> # HAVE_INT_TIMEZONE.
> >>> AC_DEFUN([PGAC_VAR_INT_TIMEZONE],
> >>> [AC_CACHE_CHECK(for int timezone, pgac_cv_var_int_timezone,
> >>> [AC_TRY_LINK([#include
> >>> int res;],
> >>> [res = timezone / 60;],
> >>> [pgac_cv_var_int_timezone=yes],
> >>> [pgac_cv_var_int_timezone=no])])
> >>> if test x"$pgac_cv_var_int_timezone" = xyes ; then
> >>> AC_DEFINE(HAVE_INT_TIMEZONE,, [Define to 1 if you have the global
> >>> variable 'int timezone'.])
> >>> fi])# PGAC_VAR_INT_TIMEZONE
> >>>
> >>>You can look in include/pg_config.h to see how it is defined.
> >>
> >>This test fails, because you cannot do arithmetic with time_t.
> >>cygwin has/had a special workaround in pg_config_manual.h
> >>See Tom above.
>
> sorry, my mistake. you can do arithmetic with time_t.
>
> >>All other platforms with time_t timezone should manually enable their
> >>HAVE_INT_TIMEZONE and manually add the (int) timezone in
> >>src/timezone/pgtz.c.
> >
> > OK, let's get some facts. How is your timezone variable defined in your
> > headers? Is it _timezone? How is time_t defined? If you take the
> > program above and compile it alone, how does it fail?
>
> yes, it's only _timezone.
>
> already sent to this list. here it is:
>
> /usr/include/time.h from newlib.
> ...
> /* defines for the opengroup specifications Derived from Issue 1 of the
> SVID. */
> extern __IMPORT time_t _timezone;
> extern __IMPORT int _daylight;
> extern __IMPORT char *_tzname[2];
>
> which resolves to (gcc -E):
> # 98 "/usr/include/time.h" 3 4
> extern __attribute__((dllimport)) time_t _timezone;
> extern __attribute__((dllimport)) int _daylight;
> extern __attribute__((dllimport)) char *_tzname[2];
>
> time_t is a typedef from sys/types.h:
> #ifndef __time_t_defined
> typedef _TIME_T_ time_t;
> #define __time_t_defined
>
> _TIME_T_ is a macro from machine/types.h:
> define _TIME_T_long
>
> > Also, look at your config.log output to see why it fails or email it to
> > my privately.
> ...
> configure:12843: checking for int timezone
> configure:12865: gcc -o conftest.exe -O2 -fno-strict-aliasing -Wall
> -Wmissing-prototypes -Wmissing-declarations -fno-strict-aliasing
> -L/usr/local/lib conftest.c -lssl -lcrypto -lz -lreadline -lcrypt
> -lresolv -lm >&5
> conftest.c: In function `main':
> conftest.c:67: error: invalid operands to binary /
> configure:12871: $? = 1
> configure: failed program was:
> ...
>
> #include
> int res;
> int
> main ()
> {
> res = timezone / 60;
>;
>return 0;
> }
>
> so my patch and my whole point is wrong.
> just the underscore is needed for cygwin in pg_config_manual.h
> --
> Reini Urban
> http://xarch.tu-graz.ac.at/home/rurban/
>
> ---(end of broadcast)---
> TIP 7: don't forget to increase your free space map settings
>
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
Index: configure
===
RCS file: /cvsroot/pgsql-server/configure,v
retrieving revision 1.389
diff -c -c -r1.389 configure
*** configure 2 Sep 2004 20:39:57 - 1.389
--- configure 8 Sep 2004 19:36:18 -
***
*** 10725,10731
--- 10725,10735
int
main ()
{
+ #ifndef __CYGWIN__
res = timezone / 60;
+ #else
+ res = _timezone / 60;
+ #endif
;
return 0;
}
Index: config/c-library.m4
===
RCS file: /cvsroot/pgsql-server/config/c-library.m4,v
retrieving revision 1.26
diff -c -c -r1.26 c-library.m4
*** config/c-library.m4 7 Jun 2004 22:39:44 - 1.26
--- config/c-library.m4 8 Sep 2004 19:36:19 -
***
*** 10,16
[AC_CACHE_CHECK(for int timezone, pgac_cv_var_int_timezone,
[AC_TRY_LINK([#include
int res;],
! [res = timezone / 60;],
[pgac_cv_var_int_timezone=yes],
[pgac_cv_var_int_timezone=no])])
if test x"$pgac_cv_var_int_timezone" = xyes ; then
--- 10,20
[AC_CACHE_CHECK(for int timezone, pgac_cv_var_int_timezone,
[AC_TRY_LINK([#include
int res;],
! [#ifndef __CYGWIN__
! res =
[PATCHES] heap_modifytuple
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 (that grep
can find, that is). Regression test pass, no new compiler warning
generated.
--
Alvaro Herrera ()
"La verdad no siempre es bonita, pero el hambre de ella sí"
Index: src/backend/access/common/heaptuple.c
===
RCS file: /home/alvherre/cvs/pgsql-server/src/backend/access/common/heaptuple.c,v
retrieving revision 1.94
diff -c -r1.94 heaptuple.c
*** src/backend/access/common/heaptuple.c 29 Aug 2004 05:06:39 - 1.94
--- src/backend/access/common/heaptuple.c 8 Sep 2004 19:45:06 -
***
*** 662,680
*
*forms a new tuple from an old tuple and a set of replacement values.
*returns a new palloc'ed tuple.
- *
- *XXX it is misdesign that this is passed a Relation and not just a
- *TupleDesc to describe the tuple structure.
*
*/
HeapTuple
heap_modifytuple(HeapTuple tuple,
!Relation relation,
Datum *replValues,
char *replNulls,
char *replActions)
{
- TupleDesc tupleDesc = RelationGetDescr(relation);
int numberOfAttributes = tupleDesc->natts;
int attoff;
Datum *values;
--- 662,676
*
*forms a new tuple from an old tuple and a set of replacement values.
*returns a new palloc'ed tuple.
*
*/
HeapTuple
heap_modifytuple(HeapTuple tuple,
!TupleDesc tupleDesc,
Datum *replValues,
char *replNulls,
char *replActions)
{
int numberOfAttributes = tupleDesc->natts;
int attoff;
Datum *values;
Index: src/backend/catalog/aclchk.c
===
RCS file: /home/alvherre/cvs/pgsql-server/src/backend/catalog/aclchk.c,v
retrieving revision 1.107
diff -c -r1.107 aclchk.c
*** src/backend/catalog/aclchk.c29 Aug 2004 05:06:41 - 1.107
--- src/backend/catalog/aclchk.c8 Sep 2004 19:54:00 -
***
*** 373,379
replaces[Anum_pg_class_relacl - 1] = 'r';
values[Anum_pg_class_relacl - 1] = PointerGetDatum(new_acl);
! newtuple = heap_modifytuple(tuple, relation, values, nulls, replaces);
ReleaseSysCache(tuple);
--- 373,379
replaces[Anum_pg_class_relacl - 1] = 'r';
values[Anum_pg_class_relacl - 1] = PointerGetDatum(new_acl);
! newtuple = heap_modifytuple(tuple, RelationGetDescr(relation), values,
nulls, replaces);
ReleaseSysCache(tuple);
***
*** 531,537
replaces[Anum_pg_database_datacl - 1] = 'r';
values[Anum_pg_database_datacl - 1] = PointerGetDatum(new_acl);
! newtuple = heap_modifytuple(tuple, relation, values, nulls, replaces);
simple_heap_update(relation, &newtuple->t_self, newtuple);
--- 531,537
replaces[Anum_pg_database_datacl - 1] = 'r';
values[Anum_pg_database_datacl - 1] = PointerGetDatum(new_acl);
! newtuple = heap_modifytuple(tuple, RelationGetDescr(relation), values,
nulls, replaces);
simple_heap_update(relation, &newtuple->t_self, newtuple);
***
*** 685,691
replaces[Anum_pg_proc_proacl - 1] = 'r';
values[Anum_pg_proc_proacl - 1] = PointerGetDatum(new_acl);
! newtuple = heap_modifytuple(tuple, relation, values, nulls, replaces);
ReleaseSysCache(tuple);
--- 685,691
replaces[Anum_pg_proc_proacl - 1] = 'r';
values[Anum_pg_proc_proacl - 1] = PointerGetDatum(new_acl);
! newtuple = heap_modifytuple(tuple, RelationGetDescr(relation), values,
nulls, replaces);
ReleaseSysCache(tuple);
***
*** 848,854
replaces[Anum_pg_language_lanacl - 1] = 'r';
values[Anum_pg_language_lanacl - 1] = PointerGetDatum(new_acl);
! newtuple = heap_modifytuple(tuple, relation, values, nulls, replaces);
ReleaseSysCache(tuple);
--- 848,854
replaces[Anum_pg_language_lanacl - 1] = 'r';
values[Anum_pg_language_lanacl - 1] = PointerGetD
Re: [PATCHES] heap_modifytuple
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 mid-beta is a good time to be indulging in purely cosmetic cleanup ... regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] time_t timezone
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
> 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 problems in dirmod.c but have run out of time and will
> deal with them in a few days.
>
> ---
>
> Reini Urban wrote:
> > Bruce Momjian schrieb:
> >
> > > Reini Urban wrote:
> > >
> > >>> # PGAC_VAR_INT_TIMEZONE
> > >>> # -
> > >>> # Check if the global variable `timezone' exists. If so, define
> > >>> # HAVE_INT_TIMEZONE.
> > >>> AC_DEFUN([PGAC_VAR_INT_TIMEZONE],
> > >>> [AC_CACHE_CHECK(for int timezone, pgac_cv_var_int_timezone,
> > >>> [AC_TRY_LINK([#include
> > >>> int res;],
> > >>> [res = timezone / 60;],
> > >>> [pgac_cv_var_int_timezone=yes],
> > >>> [pgac_cv_var_int_timezone=no])])
> > >>> if test x"$pgac_cv_var_int_timezone" = xyes ; then
> > >>> AC_DEFINE(HAVE_INT_TIMEZONE,, [Define to 1 if you have the global
> > >>> variable 'int timezone'.])
> > >>> fi])# PGAC_VAR_INT_TIMEZONE
> > >>>
> > >>>You can look in include/pg_config.h to see how it is defined.
> > >>
> > >>This test fails, because you cannot do arithmetic with time_t.
> > >>cygwin has/had a special workaround in pg_config_manual.h
> > >>See Tom above.
> >
> > sorry, my mistake. you can do arithmetic with time_t.
> >
> > >>All other platforms with time_t timezone should manually enable their
> > >>HAVE_INT_TIMEZONE and manually add the (int) timezone in
> > >>src/timezone/pgtz.c.
> > >
> > > OK, let's get some facts. How is your timezone variable defined in your
> > > headers? Is it _timezone? How is time_t defined? If you take the
> > > program above and compile it alone, how does it fail?
> >
> > yes, it's only _timezone.
> >
> > already sent to this list. here it is:
> >
> > /usr/include/time.h from newlib.
> > ...
> > /* defines for the opengroup specifications Derived from Issue 1 of the
> > SVID. */
> > extern __IMPORT time_t _timezone;
> > extern __IMPORT int _daylight;
> > extern __IMPORT char *_tzname[2];
> >
> > which resolves to (gcc -E):
> > # 98 "/usr/include/time.h" 3 4
> > extern __attribute__((dllimport)) time_t _timezone;
> > extern __attribute__((dllimport)) int _daylight;
> > extern __attribute__((dllimport)) char *_tzname[2];
> >
> > time_t is a typedef from sys/types.h:
> > #ifndef __time_t_defined
> > typedef _TIME_T_ time_t;
> > #define __time_t_defined
> >
> > _TIME_T_ is a macro from machine/types.h:
> > define _TIME_T_long
> >
> > > Also, look at your config.log output to see why it fails or email it to
> > > my privately.
> > ...
> > configure:12843: checking for int timezone
> > configure:12865: gcc -o conftest.exe -O2 -fno-strict-aliasing -Wall
> > -Wmissing-prototypes -Wmissing-declarations -fno-strict-aliasing
> > -L/usr/local/lib conftest.c -lssl -lcrypto -lz -lreadline -lcrypt
> > -lresolv -lm >&5
> > conftest.c: In function `main':
> > conftest.c:67: error: invalid operands to binary /
> > configure:12871: $? = 1
> > configure: failed program was:
> > ...
> >
> > #include
> > int res;
> > int
> > main ()
> > {
> > res = timezone / 60;
> >;
> >return 0;
> > }
> >
> > so my patch and my whole point is wrong.
> > just the underscore is needed for cygwin in pg_config_manual.h
> > --
> > Reini Urban
> > http://xarch.tu-graz.ac.at/home/rurban/
> >
> > ---(end of broadcast)---
> > TIP 7: don't forget to increase your free space map settings
> >
>
> --
> Bruce Momjian| http://candle.pha.pa.us
> [EMAIL PROTECTED] | (610) 359-1001
> + If your life is a hard drive, | 13 Roberts Road
> + Christ can be your backup.| Newtown Square, Pennsylvania 19073
> Index: configure
> ===
> RCS file: /cvsroot/pgsql-server/configure,v
> retrieving revision 1.389
> diff -c -c -r1.389 configure
> *** configure 2 Sep 2004 20:39:57 - 1.389
> --- configure 8 Sep 2004 19:36:18 -
> ***
> *** 10725,10731
> --- 10725,10735
> int
> main ()
> {
> + #ifndef __CYGWIN__
> res = timezone / 60;
> + #else
> + res = _timezone / 60;
> + #endif
> ;
> return 0;
> }
> Index: config/c-library.m4
> ===
> RCS file: /cvsroot/pgsql-server/config/c-library.m4,v
> retrieving revision 1.26
> diff -c -c -r1.26 c-library.m4
> *** config/c-library.m4 7 Jun 2004 22:39:44 - 1.26
>
Re: [PATCHES] [pgsql-hackers-win32] Contrib modules on Win32
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.com/emailpolicy.html";>http://www.memetrics.com/em ailpolicy.html diff.patch Description: Binary data ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] [pgsql-hackers-win32] Contrib modules on Win32
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_utils.patch Description: Binary data ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
