Re: [pgsql-patches] pg_dumpall -f filename option
Bruce Momjian wrote: Patch applied. Thanks. Docs updated to mention Win32: Write the output to the specified file. This is particularly useful on Windows because output redirection does not work for child processes. I didn't say that - I said that I couldn't redirect the output from the child processes in pgAdmin which is a limitation of the way wxWidgets works from what I can tell. It may (in fact, quite possibly does) apply to *nix as well. pg_dumpall output can be redirected from a command prompt on Windows without any problem. The patch was proposed in this case because a) it gives pg_dumpall more consistency with pg_dump allowing pgAdmin to use pg_duampall in the same way it already uses pg_dump, and b) I have a vague chance of getting a patch into pg_dumpall this century :-) Regards, Dave. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[pgsql-patches] Getting rid of warnings
Attached patch gets rid of most of the remaining warnings on a VC++
build. Summary is:
* A bunch of places that had different const specifyer in the header and
in the body of the function. (contrib/intarray, src/timezone)
* 1.2 and such constants are double and cause warning. Define as floats
(contrib/pg_trgm and contrib/tsearch2)
* HAVE_STRERROR is defined by python, so only conditionally redefine it
in pg_config.h
* NULL function pointer in SSL call cast to the correct pointer type
* ssize_t is defined in pg_config_os.h, remove from libpq-int.h
* Always skip warning 4102 (label nnn: unreferenced label) caused by
bison.
* Support for ignoring linker warnings, and ignore the warning about
PRIVATE on DllRegisterServer. Can't fix properly because PRIVATE is
not supported by mingw.
Index: contrib/intarray/_int_tool.c
===
RCS file: /projects/cvsroot/pgsql/contrib/intarray/_int_tool.c,v
retrieving revision 1.8
diff -c -r1.8 _int_tool.c
*** contrib/intarray/_int_tool.c4 Oct 2006 00:29:45 - 1.8
--- contrib/intarray/_int_tool.c25 Jan 2007 12:16:46 -
***
*** 188,194
/* len = 2 */
bool
! isort(int4 *a, int len)
{
int4tmp,
index;
--- 188,194
/* len = 2 */
bool
! isort(int4 *a, const int len)
{
int4tmp,
index;
Index: contrib/pg_trgm/trgm_op.c
===
RCS file: /projects/cvsroot/pgsql/contrib/pg_trgm/trgm_op.c,v
retrieving revision 1.5
diff -c -r1.5 trgm_op.c
*** contrib/pg_trgm/trgm_op.c 30 May 2006 22:12:13 - 1.5
--- contrib/pg_trgm/trgm_op.c 25 Jan 2007 12:18:05 -
***
*** 5,11
PG_MODULE_MAGIC;
! float4trgm_limit = 0.3;
PG_FUNCTION_INFO_V1(set_limit);
Datum set_limit(PG_FUNCTION_ARGS);
--- 5,11
PG_MODULE_MAGIC;
! float4trgm_limit = 0.3f;
PG_FUNCTION_INFO_V1(set_limit);
Datum set_limit(PG_FUNCTION_ARGS);
Index: contrib/tsearch2/rank.c
===
RCS file: /projects/cvsroot/pgsql/contrib/tsearch2/rank.c,v
retrieving revision 1.21
diff -c -r1.21 rank.c
*** contrib/tsearch2/rank.c 28 Dec 2006 01:09:01 - 1.21
--- contrib/tsearch2/rank.c 25 Jan 2007 12:19:30 -
***
*** 37,43
PG_FUNCTION_INFO_V1(get_covers);
Datum get_covers(PG_FUNCTION_ARGS);
! static float weights[] = {0.1, 0.2, 0.4, 1.0};
#define wpos(wep) ( w[ WEP_GETWEIGHT(wep) ] )
--- 37,43
PG_FUNCTION_INFO_V1(get_covers);
Datum get_covers(PG_FUNCTION_ARGS);
! static float weights[] = {0.1f, 0.2f, 0.4f, 1.0f};
#define wpos(wep) ( w[ WEP_GETWEIGHT(wep) ] )
***
*** 59,65
word_distance(int4 w)
{
if (w 100)
! return 1e-30;
return 1.0 / (1.005 + 0.05 * exp(((float4) w) / 1.5 - 2));
}
--- 59,65
word_distance(int4 w)
{
if (w 100)
! return (float4)1e-30;
return 1.0 / (1.005 + 0.05 * exp(((float4) w) / 1.5 - 2));
}
***
*** 331,337
calc_rank_and(w, t, q) : calc_rank_or(w, t, q);
if (res 0)
! res = 1e-20;
if ((method RANK_NORM_LOGLENGTH) t-size 0)
res /= log((double) (cnt_length(t) + 1)) / log(2.0);
--- 331,337
calc_rank_and(w, t, q) : calc_rank_or(w, t, q);
if (res 0)
! res = (float)1e-20;
if ((method RANK_NORM_LOGLENGTH) t-size 0)
res /= log((double) (cnt_length(t) + 1)) / log(2.0);
Index: src/include/pg_config.h.win32
===
RCS file: /projects/cvsroot/pgsql/src/include/pg_config.h.win32,v
retrieving revision 1.39
diff -c -r1.39 pg_config.h.win32
*** src/include/pg_config.h.win32 5 Jan 2007 20:54:39 - 1.39
--- src/include/pg_config.h.win32 25 Jan 2007 13:10:02 -
***
*** 366,372
--- 366,374
#define HAVE_STRDUP 1
/* Define to 1 if you have the `strerror' function. */
+ #ifndef HAVE_STRERROR
#define HAVE_STRERROR 1
+ #endif
/* Define to 1 if you have the `strerror_r' function. */
/* #undef HAVE_STRERROR_R */
Index: src/interfaces/libpq/fe-secure.c
===
RCS file: /projects/cvsroot/pgsql/src/interfaces/libpq/fe-secure.c,v
retrieving revision 1.90
diff -c -r1.90 fe-secure.c
*** src/interfaces/libpq/fe-secure.c5 Jan 2007 22:20:01 - 1.90
--- src/interfaces/libpq/fe-secure.c25 Jan 2007 13:21:17 -
***
*** 642,648
return 0;
}
#endif
! if (PEM_read_PrivateKey(fp, pkey, cb, NULL) == NULL)
{
char *err =
Re: [pgsql-patches] Getting rid of warnings
Magnus Hagander wrote: * NULL function pointer in SSL call cast to the correct pointer type Why not write NULL? In the alternative, declare the variable to have the right type to begin with. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [pgsql-patches] Getting rid of warnings
On Thu, Jan 25, 2007 at 03:29:50PM +0100, Peter Eisentraut wrote: Magnus Hagander wrote: * NULL function pointer in SSL call cast to the correct pointer type Why not write NULL? In the alternative, declare the variable to have the right type to begin with. I went down the path of least resistance :-) Not sure if there was a reason to code it that way from the beginning. NULL works equally well (tested). I assume this change is something ac ommitter can take care of at commit-time, so I'll not resubmit for it unless asked to. //Magnus ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [pgsql-patches] [HACKERS] Fix for bug in plpython bool type conversion
I have had to reverse out this patch because Py_RETURN_TRUE is only
supported in Python versions = 2.3, and we support older versions. I
did add a comment:
* We would like to use Py_RETURN_TRUE and Py_RETURN_FALSE here for
* generating SQL from trigger functions, but those are only
* supported in Python = 2.3, and we support older
* versions. http://docs.python.org/api/boolObjects.html
---
bruce wrote:
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Guido Goldstein wrote:
Hi!
The attached patch fixes a bug in plpython.
This bug was found while creating sql from trigger functions
written in plpython and later running the generated sql.
The problem was that boolean was was silently converted to
integer, which is ok for python but fails when the created
sql is used.
The patch uses the Py_RETURN_xxx macros shown at
http://docs.python.org/api/boolObjects.html .
It would be nice if someone could test and comment
on the patch.
Cheers
Guido
--- postgresql-8.2.1.orig/src/pl/plpython/plpython.c2006-11-21
22:51:05.0 +0100
+++ postgresql-8.2.1/src/pl/plpython/plpython.c 2007-01-17
18:06:58.185497734 +0100
@@ -1580,8 +1580,8 @@
PLyBool_FromString(const char *src)
{
if (src[0] == 't')
- return PyInt_FromLong(1);
- return PyInt_FromLong(0);
+ Py_RETURN_TRUE;
+ Py_RETURN_FALSE;
}
static PyObject *
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDBhttp://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDBhttp://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
Re: [pgsql-patches] pg_dumpall -f filename option
Dave Page wrote: Bruce Momjian wrote: Patch applied. Thanks. Docs updated to mention Win32: Write the output to the specified file. This is particularly useful on Windows because output redirection does not work for child processes. I didn't say that - I said that I couldn't redirect the output from the child processes in pgAdmin which is a limitation of the way wxWidgets works from what I can tell. It may (in fact, quite possibly does) apply to *nix as well. pg_dumpall output can be redirected from a command prompt on Windows without any problem. The patch was proposed in this case because a) it gives pg_dumpall more consistency with pg_dump allowing pgAdmin to use pg_duampall in the same way it already uses pg_dump, and b) I have a vague chance of getting a patch into pg_dumpall this century :-) OK, thanks. I have copied the text from pg_dump -f option now. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[pgsql-patches] setlocal to build.bat
This patch adds a setlocal command to the beginning of build.bat. This is required to deal with buildenv.bat properly, so that PATH (for example) doesn't expand infintly. Per report from Joachim Wieland. //Magnus Index: src/tools/msvc/build.bat === RCS file: /projects/cvsroot/pgsql/src/tools/msvc/build.bat,v retrieving revision 1.4 diff -c -r1.4 build.bat *** src/tools/msvc/build.bat16 Jan 2007 21:43:19 - 1.4 --- src/tools/msvc/build.bat25 Jan 2007 15:08:26 - *** *** 1,4 --- 1,5 @echo off + SETLOCAL SET STARTDIR=%CD% if exist src\tools\msvc\buildenv.bat call src\tools\msvc\buildenv.bat if exist buildenv.bat call buildenv.bat ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [pgsql-patches] Getting rid of warnings
Magnus Hagander [EMAIL PROTECTED] writes:
bool
! isort(int4 *a, int len)
{
bool
! isort(int4 *a, const int len)
{
If VC thinks that that is required to fix a warning, it's too broken to live.
AFAICS what you've got there is a compiler that is being pedantically
strict about language details that it does not actually understand well;
its apparent idea that const ** means const * const * being much in
the same line as this one.
I don't mind the non-const-related parts of this patch, but I recommend
rejecting all the const-decoration changes.
regards, tom lane
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
Re: [pgsql-patches] Getting rid of warnings
On Thu, Jan 25, 2007 at 10:57:29AM -0500, Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
bool
! isort(int4 *a, int len)
{
bool
! isort(int4 *a, const int len)
{
If VC thinks that that is required to fix a warning, it's too broken to live.
AFAICS what you've got there is a compiler that is being pedantically
strict about language details that it does not actually understand well;
its apparent idea that const ** means const * const * being much in
the same line as this one.
Not sure I understand.
The header had:
isort(int4 *a, const int len)
and the code had
isort(int4 *a, int len)
Where does the ** part come in there? It's not even a pointer!
I see the ** part for the free()/pfree() issues, but the one you're
quoting there is completely different. This is, AFAICS, a case of the
header not matching the body.
I'm fine with having that one rejected as well, and weill just file that
away as an expected-please-ignore warning, but I'd prefer to understand
why :)
//Magnus
---(end of broadcast)---
TIP 6: explain analyze is your friend
Re: [pgsql-patches] Getting rid of warnings
On Thu, 2007-01-25 at 17:11 +0100, Magnus Hagander wrote: The header had: isort(int4 *a, const int len) and the code had isort(int4 *a, int len) ISTM that the const keyword to an int function argument is pointless, so the right fix is to remove the const from the declaration in the header. Where does the ** part come in there? It's not even a pointer! I believe Tom was just referencing that as an example of a less-than-perfect compiler warning from VC++. -Neil ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [pgsql-patches] Getting rid of warnings
Magnus Hagander [EMAIL PROTECTED] writes: Not sure I understand. The header had: isort(int4 *a, const int len) and the code had isort(int4 *a, int len) Oh, I see. Yeah, that's inconsistent, though my thought would be to remove the (rather useless) const decoration in the header. I believe this coding is actually legal per C99, though, precisely because the version in the header is only decoration --- callers of the function do not care whether it thinks the parameter value is immutable inside itself. The one at the function definition site is what counts ... regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [pgsql-patches] guid/uuid datatype
On Sun, 2007-01-21 at 00:17 +0100, Gevik Babakhani wrote: So.. do we agree for uuid to be included in the core? I'd be curious to know the degree to which the proposed patch is consistent with RFC 4122, which AFAIK is the most recent relevant standard. With regard to functions for generating UUIDs, I think we should at least include the methods specified by RFC 4122 that can be implemented without too many unportable assumptions. I believe that means MD5 SHA1 hashing of an arbitrary identifier, and UUIDs generated via a PSRNG. -Neil ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [pgsql-patches] guid/uuid datatype
Neil Conway wrote: On Sun, 2007-01-21 at 00:17 +0100, Gevik Babakhani wrote: So.. do we agree for uuid to be included in the core? I'd be curious to know the degree to which the proposed patch is consistent with RFC 4122, which AFAIK is the most recent relevant standard. With regard to functions for generating UUIDs, I think we should at least include the methods specified by RFC 4122 that can be implemented without too many unportable assumptions. I believe that means MD5 SHA1 hashing of an arbitrary identifier, and UUIDs generated via a PSRNG. I thought the consensus was to provide the only atatype initially and look into providing the generator functions later or via an external project (pgfoundry or contrib/). Stefan ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [pgsql-patches] guid/uuid datatype
Gevik Babakhani wrote: So.. do we agree for uuid to be included in the core? I suggest that you read the discussion in the tsearch thread about figuring out how to make contrib modules more attractive. I don't see a reason why uuid has to be in the core, but I do see that there needs to be some centrally organized consolidation of the various existing attempts under a label of officiality. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgsql-patches] guid/uuid datatype
On Thu, 2007-01-25 at 17:57 +0100, Stefan Kaltenbrunner wrote: I thought the consensus was to provide the only atatype initially and look into providing the generator functions later or via an external project (pgfoundry or contrib/). I don't think distributing the (portable) generator functions separately makes a lot of sense. For the generation methods that just depend on md5() or random(), we may as well include them in the backend if we're going to include the rest of the UUID stuff. The MAC-based generator function could also be included in the backend, actually: it just needs to take an argument of type macaddr. It would then be up to the user (and/or various pgfoundry and contrib/ modules) to find a way to determine the local machine's MAC address, which presumably can't be done reliably in a portable fashion. -Neil ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [pgsql-patches] guid/uuid datatype
Peter Eisentraut wrote: Gevik Babakhani wrote: So.. do we agree for uuid to be included in the core? I suggest that you read the discussion in the tsearch thread about figuring out how to make contrib modules more attractive. I don't see a reason why uuid has to be in the core, but I do see that there needs to be some centrally organized consolidation of the various existing attempts under a label of officiality. I think it would be more important to determine how we can get UUID in core. It is a known and accepted way of doing things in the marketplace and professional communities. It is time we stop fighting features for the sake of fighting features. Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [pgsql-patches] guid/uuid datatype
Neil Conway wrote: On Thu, 2007-01-25 at 17:57 +0100, Stefan Kaltenbrunner wrote: I thought the consensus was to provide the only atatype initially and look into providing the generator functions later or via an external project (pgfoundry or contrib/). I don't think distributing the (portable) generator functions separately makes a lot of sense. For the generation methods that just depend on md5() or random(), we may as well include them in the backend if we're going to include the rest of the UUID stuff. The MAC-based generator function could also be included in the backend, actually: it just needs to take an argument of type macaddr. It would then be up to the user (and/or various pgfoundry and contrib/ modules) to find a way to determine the local machine's MAC address, which presumably can't be done reliably in a portable fashion. I assume we could just allow the MAC address or some unique idenfier to be specified in postgesql.conf. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [pgsql-patches] guid/uuid datatype
The MAC-based generator function could also be included in the backend, actually: it just needs to take an argument of type macaddr. It would then be up to the user (and/or various pgfoundry and contrib/ modules) to find a way to determine the local machine's MAC address, which presumably can't be done reliably in a portable fashion. I assume we could just allow the MAC address or some unique idenfier to be specified in postgesql.conf. Well at that point why don't we allow it to be specified per database? ALTER DATABASE foo SET uuid_salt = :) That would be pretty cool, but I am sure most will shoot that down in flames :) Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgsql-patches] guid/uuid datatype
I thought the consensus was to provide the only atatype initially and look into providing the generator functions later or via an external project (pgfoundry or contrib/). This was my understanding too... to include the uuid in the core and let the actual value be generated elsewhere...(client or separate project)... I do not think having a uuid datatype as contrib module separately will do us much good. All professional dbs support this as built in. So why shouldn't we... Regards, Gevik. ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [pgsql-patches] setlocal to build.bat
Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches It will be applied as soon as one of the PostgreSQL committers reviews and approves it. --- Magnus Hagander wrote: This patch adds a setlocal command to the beginning of build.bat. This is required to deal with buildenv.bat properly, so that PATH (for example) doesn't expand infintly. Per report from Joachim Wieland. //Magnus [ Attachment, skipping... ] ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 1: 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: [pgsql-patches] setlocal to build.bat
On Thu, 2007-01-25 at 16:11 +0100, Magnus Hagander wrote: This patch adds a setlocal command to the beginning of build.bat. This is required to deal with buildenv.bat properly, so that PATH (for example) doesn't expand infintly. Per report from Joachim Wieland. Applied, thanks. -Neil ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [pgsql-patches] setlocal to build.bat
Applied by Neil. --- Magnus Hagander wrote: This patch adds a setlocal command to the beginning of build.bat. This is required to deal with buildenv.bat properly, so that PATH (for example) doesn't expand infintly. Per report from Joachim Wieland. //Magnus [ Attachment, skipping... ] ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [pgsql-patches] Getting rid of warnings
I need an updated version of this to apply. The suggested changes are too extensive. --- Magnus Hagander wrote: Attached patch gets rid of most of the remaining warnings on a VC++ build. Summary is: * A bunch of places that had different const specifyer in the header and in the body of the function. (contrib/intarray, src/timezone) * 1.2 and such constants are double and cause warning. Define as floats (contrib/pg_trgm and contrib/tsearch2) * HAVE_STRERROR is defined by python, so only conditionally redefine it in pg_config.h * NULL function pointer in SSL call cast to the correct pointer type * ssize_t is defined in pg_config_os.h, remove from libpq-int.h * Always skip warning 4102 (label nnn: unreferenced label) caused by bison. * Support for ignoring linker warnings, and ignore the warning about PRIVATE on DllRegisterServer. Can't fix properly because PRIVATE is not supported by mingw. [ Attachment, skipping... ] ---(end of broadcast)--- TIP 1: 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 -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgsql-patches] Getting rid of warnings
Bruce Momjian wrote: I need an updated version of this to apply. The suggested changes are too extensive. I'll try to do this tomorrow. If I get it right, the changes needed are: NULL instead of cast of function ptr, per Peter. Do the const-change in the other direction in contrib/intarray. The patch never contained anything for those const ** warnings, so I'll just continue not to include those. If I missed anything, let me know :-) //Magnus ---(end of broadcast)--- TIP 1: 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: [pgsql-patches] Getting rid of warnings
Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: Not sure I understand. The header had: isort(int4 *a, const int len) and the code had isort(int4 *a, int len) Oh, I see. Yeah, that's inconsistent, though my thought would be to remove the (rather useless) const decoration in the header. I believe this coding is actually legal per C99, though, precisely because the version in the header is only decoration --- callers of the function do not care whether it thinks the parameter value is immutable inside itself. The one at the function definition site is what counts ... If it wasn't legal, it should be an error and not a warning. I would guess it's a warning simply so you should be aware that it's ignored. I'll update the patch for it. //Magnus ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
[pgsql-patches] uuid patch 2.0 (8.3devel)
Folks,
Hereby the version 2.0 of the uuid datatype patch with modifications
commented by Neil.
- the uuid.h has been cleaned.
the declarations have been moved to uuid.c
- the text_uuid() and varchar_uuid() have been refactored.
- all uuid explicit functions are moved to uuid.c and made local.
* this patch has been tested on 8.3devel, the snapshot of 25-Jan-07
* this patch uses 28 new oids. I have assigned the oids from 2950.
If you need to change the oids, do not do this manually. I have a script
that does that. Just provide me 28 unused oids and I will generate a new
patch.
Please provide comments.
Regards,
Gevik
###
# Patch created by PostgreSQL Patch Generator 1.0
# Written by Gevik Babakhani 2007 (BSD)
#
# Apply this patch:
# cd ./mydir.../pgsql/
# patch -p0 this.patch.file.diff
#
# Date created: Thu, 25 Jan 2007 22:21:21 +0100
#
# New files:
#./src/backend/utils/adt/uuid.c
#./src/include/utils/uuid.h
#./src/test/regress/expected/uuid.out
#./src/test/regress/sql/uuid.sql
# Modified files:
#./src/backend/utils/adt/Makefile
#./src/include/catalog/pg_amop.h
#./src/include/catalog/pg_amproc.h
#./src/include/catalog/pg_cast.h
#./src/include/catalog/pg_opclass.h
#./src/include/catalog/pg_operator.h
#./src/include/catalog/pg_opfamily.h
#./src/include/catalog/pg_proc.h
#./src/include/catalog/pg_type.h
#./src/include/utils/builtins.h
#./src/test/regress/parallel_schedule
#./src/test/regress/serial_schedule
##
*** ./src/backend/utils/adt/Makefile.orig 2007-01-24 16:35:05.0 +0100
--- ./src/backend/utils/adt/Makefile 2007-01-24 16:37:12.0 +0100
***
*** 15,21
endif
endif
! OBJS = acl.o arrayfuncs.o array_userfuncs.o arrayutils.o bool.o \
cash.o char.o date.o datetime.o datum.o domains.o \
float.o format_type.o \
geo_ops.o geo_selfuncs.o int.o int8.o like.o lockfuncs.o \
--- 15,21
endif
endif
! OBJS = uuid.o acl.o arrayfuncs.o array_userfuncs.o arrayutils.o bool.o \
cash.o char.o date.o datetime.o datum.o domains.o \
float.o format_type.o \
geo_ops.o geo_selfuncs.o int.o int8.o like.o lockfuncs.o \
*** ./src/backend/utils/adt/uuid.c.orig 1970-01-01 01:00:00.0 +0100
--- ./src/backend/utils/adt/uuid.c 2007-01-24 17:54:54.0 +0100
***
*** 0
--- 1,271
+ /*-
+ *
+ * uuid.h
+ * Header file for the SQL datatypes UUID.
+ *
+ * Portions Copyright (c) 1996-2006, PostgreSQL Global Development Group
+ *
+ *-
+ */
+
+ #include postgres.h
+ #include access/hash.h
+ #include libpq/pqformat.h
+ #include utils/builtins.h
+ #include utils/uuid.h
+
+ /* declarations */
+
+ static void create_uuiddata_from_string(const char* source,unsigned char *data);
+ static bool parse_uuid_string(const char* fmt,const char* source,unsigned char* data);
+ static void create_string_form_uuid_data(const char* fmt,const char *data,char *uuid_str);
+ static int32 uuid_internal_cmp(uuid_t *arg1,uuid_t *arg2);
+ static Datum cast_text_to_uuid(text *input);
+
+ /*
+ * function handles input for the uuid datatype
+ */
+ Datum uuid_in(PG_FUNCTION_ARGS)
+ {
+ uuid_t *uuid;
+ uint8 data[UUID_LEN];
+
+ char *uuid_str = PG_GETARG_CSTRING(0);
+
+ create_uuiddata_from_string(uuid_str,data);
+
+ uuid = (uuid_t *) palloc(sizeof(uuid_t));
+ memcpy(uuid-data,data,UUID_LEN);
+
+ PG_RETURN_UUID_P(uuid);
+ }
+
+ /*
+ * function handles output for the uuid datatype
+ */
+ Datum uuid_out(PG_FUNCTION_ARGS)
+ {
+ uuid_t *uuid = (uuid_t *) PG_GETARG_POINTER(0);
+
+ char *uuid_str;
+
+ uuid_str = (char *)palloc(PRINT_SIZE);
+ create_string_form_uuid_data(UUID_FMT1,uuid-data,uuid_str);
+
+ PG_RETURN_CSTRING(uuid_str);
+ }
+
+ /* uuid binary receive handler */
+ Datum uuid_recv(PG_FUNCTION_ARGS)
+ {
+ uuid_t *uuid;
+ StringInfo buffer = (StringInfo) PG_GETARG_POINTER(0);
+
+ uuid = (uuid_t *)palloc(UUID_LEN);
+ memcpy(uuid-data,pq_getmsgbytes(buffer,UUID_LEN),UUID_LEN);
+ PG_RETURN_POINTER(uuid);
+ }
+
+ /* uuid binary send handler */
+ Datum uuid_send(PG_FUNCTION_ARGS)
+ {
+ uuid_t *uuid = PG_GETARG_UUID_P(0);
+ StringInfoData buffer;
+
+ pq_begintypsend(buffer);
+ pq_sendbytes(buffer,uuid-data,UUID_LEN);
+ PG_RETURN_BYTEA_P(pq_endtypsend(buffer));
+ }
+
+ /* handler for operator */
+ Datum uuid_lt(PG_FUNCTION_ARGS)
+ {
+ bool result;
+ uuid_t *arg1 = PG_GETARG_UUID_P(0);
+ uuid_t *arg2 = PG_GETARG_UUID_P(1);
+
+ result = uuid_internal_cmp(arg1,arg2) 0;
+
Re: [pgsql-patches] [HACKERS] Win32 WEXITSTATUS too
Chuck McDevitt wrote: Win32 exception codes start with a two-bit severity indication. 00 means success, so nothing is wrong. 01 is an informational messages. 10 is a warning message. 11 is an error. That's why the common exception codes you see start with hex C0, as they are errors. The rest of the top 16 bits are the facility that caused the error. Often not filled in. To Convert an NT exception code (ntstatus) to a Win32 error code, you call this routine: ULONG RtlNtStatusToDosError( NTSTATUS Status ); Then you can pass it to FormatMessage and it will work. I looked on MinGW and it seems it doesn't support RtlNtStatusToDosError(), so I just added a comment that some day we might want to use it: * Some day we might want to print descriptions for the most common * exceptions, rather than printing an include file name. We could use * RtlNtStatusToDosError() and pass to FormatMessage(), which can print * the text of error values, but MinGW does not support * RtlNtStatusToDosError(). --- -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Momjian Sent: Tuesday, January 23, 2007 7:35 AM To: Tom Lane Cc: Magnus Hagander; Takayuki Tsunakawa; PostgreSQL-patches; Alvaro Herrera; ITAGAKI Takahiro Subject: Re: [pgsql-patches] [HACKERS] Win32 WEXITSTATUS too Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Magnus Hagander wrote: Now, if we're only caring about exit() from *postgresqls own processes*, that might hold true. In which case I withdraw that objection as long as the comment i updated to reflect this ;-) But if we're talking about exit() in general of any process, then it's simply wrong. Right, that code is only used by the backend and tools. We can reasonably assume that no Postgres code will exit() with a value bigger than 255, because to do so would be unportable. I'm more concerned about the other direction: can we be sure that a status value less than 255 is from exit() rather than something that should be called an exception? ---(end of broadcast)--- TIP 1: 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 -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgsql-patches] uuid patch 2.0 (8.3devel)
Gevik Babakhani wrote: Hereby the version 2.0 of the uuid datatype patch with modifications If I may make some comments on style: Put your file at the end of the OBJS variable (or in some sort of sensible order). Put your file at the end of the tests (or in some sort of sensible order). Refrain from self-evident comments, such as + /* + * function handles input for the uuid datatype + */ + Datum uuid_in(PG_FUNCTION_ARGS) You can probably delete all comments in your patch by that criterion. This sort of super-verbose coding might be alright, but it gets tiring when done systematically for no reason: + result = DirectFunctionCall1(textin, uuid_str); + return result; The uuid.c file claims it is uuid.h. Move the stuff from builtins.h to uuid.h. Move the stuff from uuid.h that is not needed anywhere else to uuid.c. No // comments. Don't number the tests. We might want to insert something later and that would mess everything up. Capitalize the SQL test scripts as in other files. Remove gratuitous whitespace changes (there are many). Also remove the whitespace at the end of lines. Make some reasonable effort to align the catalog entries for readability. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [pgsql-patches] [HACKERS] unprivileged contrib and pl install
On Wed, 24 Jan 2007, Jeremy Drake wrote:
On Wed, 24 Jan 2007, Tom Lane wrote:
In detail, it'd look something like:
* For an untrusted language: must be superuser to either create or use
the language (no change from current rules). Ownership of the
pg_language entry is really irrelevant, as is its ACL.
* For a trusted language:
* if pg_pltemplate.something is ON: either a superuser or the current
DB's owner can CREATE the language. In either case the pg_language
entry will be marked as owned by the DB owner (pg_database.datdba),
which means that subsequently he (or a superuser) can grant or deny
USAGE within his DB.
* if pg_pltemplate.something is OFF: must be superuser to CREATE the
language; subsequently it will be owned by you, so only you or another
superuser can grant or deny USAGE (same behavior as currently).
I think I have what is described here implemented in this patch, so that
it can be better understood. Thoughts?
This version of the patch creates a shared dependency on the language
owner.
I have thought of some other questions about the owner stuff which I will
send on -hackers...
--
Afternoon, n.:
That part of the day we spend worrying about how we wasted the
morning.Index: src/backend/catalog/aclchk.c
===
RCS file:
/data/local/jeremyd/postgres/cvsuproot/pgsql/src/backend/catalog/aclchk.c,v
retrieving revision 1.135
diff -c -r1.135 aclchk.c
*** src/backend/catalog/aclchk.c23 Jan 2007 05:07:17 - 1.135
--- src/backend/catalog/aclchk.c25 Jan 2007 06:35:21 -
***
*** 1003,1013
/*
* Get owner ID and working copy of existing ACL. If there's no
ACL,
* substitute the proper default.
-*
-* Note: for now, languages are treated as owned by the
bootstrap
-* user. We should add an owner column to pg_language instead.
*/
! ownerId = BOOTSTRAP_SUPERUSERID;
aclDatum = SysCacheGetAttr(LANGNAME, tuple,
Anum_pg_language_lanacl,
isNull);
if (isNull)
--- 1003,1010
/*
* Get owner ID and working copy of existing ACL. If there's no
ACL,
* substitute the proper default.
*/
! ownerId = pg_language_tuple-lanowner;
aclDatum = SysCacheGetAttr(LANGNAME, tuple,
Anum_pg_language_lanacl,
isNull);
if (isNull)
***
*** 1770,1777
(errcode(ERRCODE_UNDEFINED_OBJECT),
errmsg(language with OID %u does not exist,
lang_oid)));
! /* XXX pg_language should have an owner column, but doesn't */
! ownerId = BOOTSTRAP_SUPERUSERID;
aclDatum = SysCacheGetAttr(LANGOID, tuple, Anum_pg_language_lanacl,
isNull);
--- 1767,1773
(errcode(ERRCODE_UNDEFINED_OBJECT),
errmsg(language with OID %u does not exist,
lang_oid)));
! ownerId = ((Form_pg_language) GETSTRUCT(tuple))-lanowner;
aclDatum = SysCacheGetAttr(LANGOID, tuple, Anum_pg_language_lanacl,
isNull);
Index: src/backend/commands/proclang.c
===
RCS file:
/data/local/jeremyd/postgres/cvsuproot/pgsql/src/backend/commands/proclang.c,v
retrieving revision 1.71
diff -c -r1.71 proclang.c
*** src/backend/commands/proclang.c 22 Jan 2007 01:35:20 - 1.71
--- src/backend/commands/proclang.c 25 Jan 2007 23:15:45 -
***
*** 17,22
--- 17,24
#include access/heapam.h
#include catalog/dependency.h
#include catalog/indexing.h
+ #include catalog/pg_authid.h
+ #include catalog/pg_database.h
#include catalog/pg_language.h
#include catalog/pg_namespace.h
#include catalog/pg_pltemplate.h
***
*** 27,32
--- 29,35
#include miscadmin.h
#include parser/gramparse.h
#include parser/parse_func.h
+ #include utils/acl.h
#include utils/builtins.h
#include utils/fmgroids.h
#include utils/lsyscache.h
***
*** 36,50
typedef struct
{
booltmpltrusted;/* trusted? */
char *tmplhandler;/* name of handler function */
char *tmplvalidator; /* name of validator function, or NULL
*/
char *tmpllibrary;/* path of shared library */
} PLTemplate;
static void create_proc_lang(const char *languageName,
!Oid handlerOid, Oid valOid, bool trusted);
static PLTemplate
Re: [pgsql-patches] guid/uuid datatype
On Jan 25, 2007, at 11:13 AM, Peter Eisentraut wrote: I suggest that you read the discussion in the tsearch thread about figuring out how to make contrib modules more attractive. I don't see a reason why uuid has to be in the core, but I do see that there needs to be some centrally organized consolidation of the various existing attempts under a label of officiality. Following that logic we should remove all data types that aren't specified in ANSI. -- Jim Nasby[EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
