Re: [PATCHES] new aggregate functions v3
Fabien COELHO wrote:
(1) boolean-and and boolean-or aggregates named bool_and and bool_or.
they (SHOULD;-) correspond to standard sql every and some/any aggregates.
they do not have the right name as there is a problem with
the standard and the parser for some/any. Tom also think that
the standard name is misleading because NULL are ignored.
As I understand it, there's an ambiguity issue with SOME/ANY, but not
with EVERY. If so, can we implement EVERY per-spec at least? It's okay
if we just add EVERY as an alias for BOOL_AND for the sake of homogeneity.
A few trivial points:
+ /* EVERY aggregate implementation conforming to SQL 2003 standard.
+ * must be strict.
+ */
This comment is misleading if we don't actually provide an
implementation of EVERY that conforms to spec. There's a similar comment
WRT to SOME/ANY.
+ PG_FUNCTION_INFO_V1(booland_statefunc);
Not needed for builtin functions (they are assumed to be V1).
+ /* what about every? */
+ DATA(insert OID = 2517 ( bool_andPGNSP PGUID 12 t f f
f i 1 16 "16" _null_ aggregate_dummy - _null_ ));
+ DESCR("boolean-and aggregate");
+ /* what about any/some? */
Seems these questions should be removed, no?
-Neil
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [PATCHES] PITR Phase 1 - partial backport to 7.3.4, 7.3.5
We need PITR, but our legacy application can't be upgraded to 7.4 Postgresql version because of autocommit handling change. So I'll try to follow Simon development of PITR for 7.5 PITR and backport it to 7.3. Why not use replication instead? Best regards -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com PostgreSQL Replicator -- production quality replication for PostgreSQL ---(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] PITR Phase 1 - partial backport to 7.3.4, 7.3.5
Hi, tom > > I tried to backport Simon Riggs patches for 7.4.x series to 7.3.x > > with addition of python implementation of pg_arch. > > > It can be of interest if you consider to continue using 7.3 series of > > postgresql. > > Surely you jest. > Nope. We have a reason for it. > You are going to take not-yet-alpha-quality code and backport it into > a version that only those desperately concerned with stability are still > running? Pardon me for failing to get the point. > We need PITR, but our legacy application can't be upgraded to 7.4 Postgresql version because of autocommit handling change. So I'll try to follow Simon development of PITR for 7.5 PITR and backport it to 7.3. Best regards -- Igor Poteryaev ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] More network functions...
*) inet_(client|server)_(addr|port)() and necessary documentation for
the four functions.
*) area(PATH) and documentation.
*) Checks for TEMP privs when creating objects in the temp schema
(checks for any object created in a temp namespace).
*) With the above change, current_user is now being used to check if
CREATE TEMP TABLE should succeed.
[ and it gets weirder from there ]
Er, what?
Could we possibly have this separated into multiple patches with some
coherent purpose to each?
Sure.
patch-network.txt contains the following bits:
*) inet_(client|server)_(addr|port)() and necessary documentation for
the four functions.
Also, please justify the temp-related changes. I was not aware that we
had any breakage there.
patch-tmp-schema.txt contains the following bits:
*) Changes pg_namespace_aclmask() so that the superuser is always able
to create objects in the temp namespace.
*) Changes pg_namespace_aclmask() so that if this is a temp namespace,
objects are only allowed to be created in the temp namespace if the
user has TEMP privs on the database. This encompasses all object
creation, not just TEMP tables.
*) InitTempTableNamespace() checks to see if the current user, not the
session user, has access to create a temp namespace.
The first two changes are necessary to support the third change. Now
it's possible to revoke all temp table privs from non-super users and
limiting all creation of temp tables/schemas via a function that's
executed with elevated privs (security definer). Before this change,
it was not possible to have a setuid function to create a temp
table/schema if the session user had no TEMP privs.
Originally you'd brought up some concerns about security problems, but
this patch I believe addresses all of your prior concerns.
patch-area-path.txt contains:
*) Can now determine the area of a closed path.
patch-dfmgr.txt contains:
*) Small tweak to add the library path that's being expanded.
I was using $lib/foo.so and couldn't easily figure out what the error
message, "invalid macro name in dynamic library path" meant without
looking through the source code. With the path in there, at least I
know where to start looking in my config file.
-sc
Index: src/backend/utils/adt/geo_ops.c
===
RCS file: /projects/cvsroot/pgsql-server/src/backend/utils/adt/geo_ops.c,v
retrieving revision 1.84
diff -u -r1.84 geo_ops.c
--- src/backend/utils/adt/geo_ops.c 12 May 2004 22:38:44 - 1.84
+++ src/backend/utils/adt/geo_ops.c 18 May 2004 18:59:40 -
@@ -1313,6 +1313,27 @@
*-*/
Datum
+path_area(PG_FUNCTION_ARGS)
+{
+ PATH*path = PG_GETARG_PATH_P(0);
+ double area = 0.0;
+ int i,j;
+
+ if (!path->closed)
+ PG_RETURN_NULL();
+
+ for (i = 0; i < path->npts; i++) {
+ j = (i + 1) % path->npts;
+ area += path->p[i].x * path->p[j].y;
+ area -= path->p[i].y * path->p[j].x;
+ }
+
+ area *= 0.5;
+ PG_RETURN_FLOAT8(area < 0.0 ? -area : area);
+}
+
+
+Datum
path_in(PG_FUNCTION_ARGS)
{
char *str = PG_GETARG_CSTRING(0);
Index: src/include/catalog/pg_proc.h
===
RCS file: /projects/cvsroot/pgsql-server/src/include/catalog/pg_proc.h,v
retrieving revision 1.329
diff -u -r1.329 pg_proc.h
--- src/include/catalog/pg_proc.h 14 May 2004 21:42:28 - 1.329
+++ src/include/catalog/pg_proc.h 18 May 2004 18:59:41 -
@@ -1259,6 +1259,8 @@
DESCR("box height");
DATA(insert OID = 978 ( box_distance PGNSP PGUID 12 f f t f i 2 701 "603 603"
_null_ box_distance - _null_ ));
DESCR("distance between boxes");
+DATA(insert OID = 979 ( area PGNSP PGUID 12 f f t f i 1 701
"602" _null_ path_area - _null_ ));
+DESCR("area of a closed path");
DATA(insert OID = 980 ( box_intersectPGNSP PGUID 12 f f t f i 2 603 "603 603"
_null_ box_intersect - _null_ ));
DESCR("box intersection (another box)");
DATA(insert OID = 981 ( diagonal PGNSP PGUID 12 f f t f i 1 601
"603" _null_ box_diagonal - _null_ ));
Index: src/include/utils/geo_decls.h
===
RCS file: /projects/cvsroot/pgsql-server/src/include/utils/geo_decls.h,v
retrieving revision 1.43
diff -u -r1.43 geo_decls.h
--- src/include/utils/geo_decls.h 29 Nov 2003 22:41:15 - 1.43
+++ src/include/utils/geo_decls.h 18 May 2004 18:59:41 -
@@ -305,6 +305,7 @@
extern Datum box_div(PG_FUNCTION_ARGS);
/* public path routines */
+extern Datum path_area(PG_FUNCTION_ARGS);
extern Datum path_in(PG_FUNCTION_ARGS);
extern Datum path_out(PG_FUNCTION_ARGS);
extern Datum path_recv(PG_FUNCTION_ARGS);
Index: src/backend/utils/fmgr/dfmgr.c
===
RCS fil
[PATCHES] Fix for Win32 linking
Win32 can't have the same function coming from two library object files, so we make is_absolute_path() a macro so libpq doesn't use path.o. -- 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: src/include/port.h === RCS file: /cvsroot/pgsql-server/src/include/port.h,v retrieving revision 1.32 diff -c -c -r1.32 port.h *** src/include/port.h 17 May 2004 14:35:34 - 1.32 --- src/include/port.h 19 May 2004 04:18:48 - *** *** 21,27 bool set_noblock(int sock); /* Portable path handling for Unix/Win32 */ - extern bool is_absolute_path(const char *filename); extern char *first_path_separator(const char *filename); extern char *last_path_separator(const char *filename); extern void canonicalize_path(char *path); --- 21,26 *** *** 31,36 --- 30,60 extern void get_include_path(const char *my_exec_path, char *ret_path); extern void get_pkginclude_path(const char *my_exec_path, char *ret_path); extern void get_pkglib_path(const char *my_exec_path, char *ret_path); + + /* + *is_absolute_path + * + *This capability is needed by libpq and initdb.c + *On Win32, you can't reference the same object file that is + *in two different libraries (pgport and libpq), so a macro is best. + */ + #ifndef WIN32 + #define is_absolute_path(filename) \ + ( \ + ((filename)[0] == '/') \ + ) + #else + #define is_absolute_path(filename) \ + ( \ + ((filename)[0] == '/') || \ + (filename)[0] == '\\' || \ + (isalpha((filename)[0]) && (filename)[1] == ':' && \ + ((filename)[2] == '\\' || (filename)[2] == '/')) \ + ) + #endif + + + /* Portable way to find binaries */ Index: src/interfaces/libpq/Makefile === RCS file: /cvsroot/pgsql-server/src/interfaces/libpq/Makefile,v retrieving revision 1.106 diff -c -c -r1.106 Makefile *** src/interfaces/libpq/Makefile 17 May 2004 14:35:34 - 1.106 --- src/interfaces/libpq/Makefile 19 May 2004 04:18:49 - *** *** 30,36 OBJS= fe-auth.o fe-connect.o fe-exec.o fe-misc.o fe-print.o fe-lobj.o \ fe-protocol2.o fe-protocol3.o pqexpbuffer.o pqsignal.o fe-secure.o \ dllist.o md5.o ip.o wchar.o encnames.o \ ! $(filter crypt.o getaddrinfo.o inet_aton.o noblock.o pgstrcasecmp.o snprintf.o strerror.o open.o path.o thread.o, $(LIBOBJS)) ifeq ($(PORTNAME), win32) OBJS+=win32.o endif --- 30,36 OBJS= fe-auth.o fe-connect.o fe-exec.o fe-misc.o fe-print.o fe-lobj.o \ fe-protocol2.o fe-protocol3.o pqexpbuffer.o pqsignal.o fe-secure.o \ dllist.o md5.o ip.o wchar.o encnames.o \ ! $(filter crypt.o getaddrinfo.o inet_aton.o noblock.o pgstrcasecmp.o snprintf.o strerror.o open.o thread.o, $(LIBOBJS)) ifeq ($(PORTNAME), win32) OBJS+=win32.o endif *** *** 59,65 # For port modules, this only happens if configure decides the module # is needed (see filter hack in OBJS, above). ! crypt.c getaddrinfo.c inet_aton.c noblock.c pgstrcasecmp.c snprintf.c strerror.c open.c path.c thread.c: % : $(top_srcdir)/src/port/% rm -f $@ && $(LN_S) $< . md5.c ip.c: % : $(backend_src)/libpq/% --- 59,65 # For port modules, this only happens if configure decides the module # is needed (see filter hack in OBJS, above). ! crypt.c getaddrinfo.c inet_aton.c noblock.c pgstrcasecmp.c snprintf.c strerror.c open.c thread.c: % : $(top_srcdir)/src/port/% rm -f $@ && $(LN_S) $< . md5.c ip.c: % : $(backend_src)/libpq/% *** *** 85,88 rm -f $(DESTDIR)$(includedir)/libpq-fe.h $(DESTDIR)$(includedir_internal)/libpq-int.h $(DESTDIR)$(includedir_internal)/pqexpbuffer.h clean distclean maintainer-clean: clean-lib ! rm -f $(OBJS) crypt.c getaddrinfo.c inet_aton.c noblock.c pgstrcasecmp.c snprintf.c strerror.c open.c path.c thread.c dllist.c md5.c ip.c encnames.c wchar.c --- 85,88 rm -f $(DESTDIR)$(includedir)/libpq-fe.h $(DESTDIR)$(includedir_internal)/libpq-int.h $(DESTDIR)$(includedir_internal)/pqexpbuffer.h clean distclean maintainer-clean: clean-lib ! rm -f $(OBJS) crypt.c getaddrinfo.c inet_aton.c noblock.c pgstrcasecmp.c snprintf.c strerror.c open.c thread.c dllist.c md5.c ip.c encnames.c wchar.c Index: src/port/path.c === RCS file: /cvsroot/pgsql-server/src/port/path.c,v retrieving revision 1.9 diff -c -c -r1.9 path.c *** src/port/path.c 18 May 2004 03:36:45 - 1.9 --- src/port/path.c 19 May 2004 04:18:50 - *** *** 35,58 /* - *is_absolute_path - */ - bool -
Re: [PATCHES] Bug in CVS pg_dump against 7.0.x
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Christopher Kings-Lynne wrote:
> No, the patch is against 7.5 CVS. It is a tiny fix that allows it to
> dump 7.0.x database backends correctly.
>
> I submitted a fix for 7.5 dumping 7.0 previously and it was accepted :)
>
> Chris
>
> Bruce Momjian wrote:
>
> > Uh, not sure anyone would even see a 7.0.X release if we made it, and I
> > question how many are using varying[]. Your patch is now in the
> > archives, and we can point folks to it if they ask.
> >
> > ---
> >
> > Christopher Kings-Lynne wrote:
> >
> >>Hi,
> >>
> >>I know 7.0.x is pretty old, but I'm wondering if we should fix this to
> >>make it better for people upgrading.
> >>
> >>If you create a table like this in 7.0.x:
> >>
> >>CREATE TABLE address (
> >> first_name character varying(50) DEFAULT 'asdf' NOT NULL,
> >> last_name character varying(50) NOT NULL,
> >> address character varying(50),
> >> tesing character varying[]
> >>);
> >>
> >>The 7.5 pg_dump program will dump it like this:
> >>
> >>CREATE TABLE address (
> >> first_name character varying(50) DEFAULT 'asdf' NOT NULL,
> >> last_name character varying(50) NOT NULL,
> >> address character varying(50),
> >> tesing _varchar
> >>);
> >>
> >>I have attached a patch that should fix it. I haven't been able to
> >>actually test it since my dev machine and the 7.0 machine I have access
> >>to aren't connected - although it does compile. The fix is based on the
> >>7.0 psql code.
> >>
> >>Chris
> >
> >
> >>? src/bin/pg_dump/.deps
> >>? src/bin/pg_dump/common.c.working
> >>? src/bin/pg_dump/pg_dump
> >>? src/bin/pg_dump/pg_dump.c.working
> >>? src/bin/pg_dump/pg_dump.h.working
> >>? src/bin/pg_dump/pg_dumpall
> >>? src/bin/pg_dump/pg_restore
> >>Index: src/bin/pg_dump/pg_dump.c
> >>===
> >>RCS file: /projects/cvsroot/pgsql-server/src/bin/pg_dump/pg_dump.c,v
> >>retrieving revision 1.370
> >>diff -c -r1.370 pg_dump.c
> >>*** src/bin/pg_dump/pg_dump.c 24 Mar 2004 03:06:08 - 1.370
> >>--- src/bin/pg_dump/pg_dump.c 16 May 2004 14:42:55 -
> >>***
> >>*** 7726,7733
> >>--- 7726,7741
> >> myFormatType(const char *typname, int32 typmod)
> >> {
> >>char *result;
> >>+ boolisarray = false;
> >>PQExpBuffer buf = createPQExpBuffer();
> >>
> >>+ /* Handle array types */
> >>+ if (typname[0] == '_')
> >>+ {
> >>+ isarray = true;
> >>+ typname++;
> >>+ }
> >>+
> >>/* Show lengths on bpchar and varchar */
> >>if (!strcmp(typname, "bpchar"))
> >>{
> >>***
> >>*** 7770,7775
> >>--- 7778,7787
> >>appendPQExpBuffer(buf, "\"char\"");
> >>else
> >>appendPQExpBuffer(buf, "%s", fmtId(typname));
> >>+
> >>+ /* Append array qualifier for array types */
> >>+ if (isarray)
> >>+ appendPQExpBuffer(buf, "[]");
> >>
> >>result = strdup(buf->data);
> >>destroyPQExpBuffer(buf);
> >
> >
> >>---(end of broadcast)---
> >>TIP 5: Have you checked our extensive FAQ?
> >>
> >> http://www.postgresql.org/docs/faqs/FAQ.html
> >
> >
>
> ---(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
---(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] PITR Phase 1 - partial backport to 7.3.4, 7.3.5
"=?koi8-r?b?8M/UxdLRxdc=?= =?koi8-r?b?IOku5S4=?=" <[EMAIL PROTECTED]> writes: > I tried to backport Simon Riggs patches for 7.4.x series to 7.3.x > with addition of python implementation of pg_arch. > It can be of interest if you consider to continue using 7.3 series of > postgresql. Surely you jest. You are going to take not-yet-alpha-quality code and backport it into a version that only those desperately concerned with stability are still running? Pardon me for failing to get the point. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] Bug in CVS pg_dump against 7.0.x
It's not a problem, since that code path is only ever executed when dumping a 7.0 backend. It's in the MyFormatType function in pg_dump.c that is used whenever the backend doesn't have its own format_type function. Right. The patch looked dangerous to me too, until I understood the context. As-is, I think it's fine -- indeed, I think we ought to backpatch it into 7.4 branch too. Strangely enough, the 7.0.x pg_dump.c does just dump arrays as bpchar_ type, but the 7.0.x psql utility displays them as character varying[] Chris ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Bug in CVS pg_dump against 7.0.x
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes: >> Do we know that is always true? What is the issue that 7.0 needs this >> and newer released don't, and how are we sure this will not break some >> strange cases in post-7.0 releases? > It's not a problem, since that code path is only ever executed when > dumping a 7.0 backend. It's in the MyFormatType function in pg_dump.c > that is used whenever the backend doesn't have its own format_type function. Right. The patch looked dangerous to me too, until I understood the context. As-is, I think it's fine -- indeed, I think we ought to backpatch it into 7.4 branch too. regards, tom lane ---(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] More network functions...
Sean Chittenden <[EMAIL PROTECTED]> writes: > *) inet_(client|server)_(addr|port)() and necessary documentation for > the four functions. > *) area(PATH) and documentation. > *) Checks for TEMP privs when creating objects in the temp schema > (checks for any object created in a temp namespace). > *) With the above change, current_user is now being used to check if > CREATE TEMP TABLE should succeed. > [ and it gets weirder from there ] Er, what? Could we possibly have this separated into multiple patches with some coherent purpose to each? Also, please justify the temp-related changes. I was not aware that we had any breakage there. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] new aggregate functions v3
[ Use newest version.] Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches I will try to apply it within the next 48 hours. --- Fabien COELHO wrote: > > Dear patchers, > > please find attached my third patch submission for adding new aggregate > functions. This new version adds a note and some indexes in the > documentation about sql standard names for bool_and and bool_or, as > suggested by Robert Treat. It also fixes conflicts created by the removal > of shameful aclitem accessors. > > The added aggregates are: > > (1) boolean-and and boolean-or aggregates named bool_and and bool_or. > they (SHOULD;-) correspond to standard sql every and some/any aggregates. > they do not have the right name as there is a problem with > the standard and the parser for some/any. Tom also think that > the standard name is misleading because NULL are ignored. > > (2) bitwise integer aggregates named bit_and and bit_or for > int2, int4, int8 and bit types. They are not standard, but I find > them useful. I needed them once. > > > The patches adds: > > - 2 new very short strict functions for boolean aggregates in > src/backed/utils/adt/bool.c, > src/include/utils/builtins.h and src/include/catalog/pg_proc.h > > - the new aggregates declared in src/include/catalog/pg_proc.h and > src/include/catalog/pg_aggregate.h > > - some documentation and validation about these new aggregates. > > > It also updates the catalog version. It validates for me. > > Have a nice day, > > -- > Fabien Coelho - [EMAIL PROTECTED] Content-Description: [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 8: explain analyze is your friend -- 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 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] add build utilities in default install
Fabien COELHO <[EMAIL PROTECTED]> writes: > Please find attached my first submission for installing all necessary > build files (makefile, scripts...) by default. Why? They won't do anyone any good outside the original build tree. Even if modified so that they are useful (which is something that is on my to-do list), I disagree with installing them by default. See previous arguments about installing backend internal headers by default. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Win32 adjustments
Peter Eisentraut wrote: > Bruce Momjian wrote: > > I have applied the following patch with Magnus's guidance. It fixes > > some Win32 problems introduced by my relative path installs. > > > > It also removes the newline from psql for MinGW-only as posted by > > Andrew. I added a mention to the Win32 todo list so we know to > > remove it once we find the real cause. > > We don't have any NLS support for libpgport. All of these strings are > dead meat. This needs fixing. OK, how do I do that? Add _()? -- 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 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Win32 adjustments
Bruce Momjian wrote: > I have applied the following patch with Magnus's guidance. It fixes > some Win32 problems introduced by my relative path installs. > > It also removes the newline from psql for MinGW-only as posted by > Andrew. I added a mention to the Win32 todo list so we know to > remove it once we find the real cause. We don't have any NLS support for libpgport. All of these strings are dead meat. This needs fixing. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[PATCHES] More network functions...
Blah, well, guess I do need the server's address after all. The
attached patch includes:
*) inet_(client|server)_(addr|port)() and necessary documentation for
the four functions.
*) area(PATH) and documentation.
*) Checks for TEMP privs when creating objects in the temp schema
(checks for any object created in a temp namespace).
*) With the above change, current_user is now being used to check if
CREATE TEMP TABLE should succeed.
*) Now cleaning up failed getaddrinfo_all() calls.
*) The check for hintp being null has been removed, all calls to
getaddrinfo_all() are passing non-null hintp's.
*) Changed some freeaddrinfo_all() calls to make sure that the addrinfo
struct is non-null. getaddrinfo_all() can fail and return a null
addrinfo struct and can fail with a non-null addrinfo struct.
*) Updated an error message to include the library path that failed
(handy for debugging old configs that contain $lib instead of $libdir)
*) warn if getaddrinfo_all() fails on postmaster startup.
*) Functions have been updated to be inline with PostgreSQL's style too.
Comments or feedback?
test=# SELECT inet_client_addr();
inet_client_addr
--
127.0.0.1
(1 row)
test=# SELECT inet_client_port();
inet_client_port
--
52711
(1 row)
test=# SELECT inet_server_port();
inet_server_port
--
5432
(1 row)
test=# SELECT inet_server_addr();
inet_server_addr
--
127.0.0.1
(1 row)
Index: doc/src/sgml/func.sgml
===
RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml/func.sgml,v
retrieving revision 1.202
diff -u -r1.202 func.sgml
--- doc/src/sgml/func.sgml 14 May 2004 21:42:27 - 1.202
+++ doc/src/sgml/func.sgml 18 May 2004 18:59:37 -
@@ -6593,6 +6593,30 @@
+ inet_client_addr
+ inet
+ address of the remote connection
+
+
+
+ inet_client_port
+ int4
+ port of the remote connection
+
+
+
+ inet_server_addr
+ inet
+ address of the local connection
+
+
+
+ inet_server_port
+ int4
+ port of the local connection
+
+
+
session_user
name
session user name
@@ -6646,6 +6670,17 @@
they must be called without trailing parentheses.
+
+
+ inet_client_addr and
+ inet_server_addr return the IPv4 or IPv6 (if
+ configured) address of the remote or local host connecting to the
+ database, respectively. inet_client_port
+ and inet_server_port return the port number
+ of the remote or local host connecting to the database,
+ respectively. If the connection is not a network connection,
+ these functions will return NULL.
+
current_schema returns the name of the schema that is
Index: src/backend/catalog/aclchk.c
===
RCS file: /projects/cvsroot/pgsql-server/src/backend/catalog/aclchk.c,v
retrieving revision 1.98
diff -u -r1.98 aclchk.c
--- src/backend/catalog/aclchk.c11 May 2004 17:36:12 - 1.98
+++ src/backend/catalog/aclchk.c18 May 2004 18:59:37 -
@@ -1342,16 +1342,26 @@
boolisNull;
Acl*acl;
- /*
-* If we have been assigned this namespace as a temp namespace, assume
-* we have all grantable privileges on it.
-*/
- if (isTempNamespace(nsp_oid))
- return mask;
-
/* Superusers bypass all permission checking. */
if (superuser_arg(userid))
return mask;
+
+ /*
+* If we have been assigned this namespace as a temp
+* namespace, check to make sure we have CREATE permissions on
+* the database.
+*
+* Instead of returning ACLCHECK_NO_PRIV, should we return via
+* ereport() with a message about trying to create an object
+* in a TEMP namespace when GetUserId() doesn't have perms?
+*/
+ if (isTempNamespace(nsp_oid)) {
+ if (pg_database_aclcheck(MyDatabaseId, GetUserId(),
+ ACL_CREATE_TEMP) == ACLCHECK_OK)
+ return ACLCHECK_OK;
+ else
+ return ACLCHECK_NO_PRIV;
+ }
/*
* Get the schema's ACL from pg_namespace
Index: src/backend/catalog/namespace.c
===
RCS file: /projects/cvsroot/pgsql-server/src/backend/catalog/namespace.c,v
retrieving revision 1.63
diff -u -r1.63 namespace.c
--- src/backend/catalog/namespace.c 13 Feb 2004 01:08:20 - 1.63
+++ src/backend/catalog/namespace.c 18 May 2004 18:59:38 -
@@ -1640,11 +1640,11 @@
* tables. We use a nonstandard error message here since
* "databasename: permission denied" might be a tad cryptic.
*
-* Note we apply the
[PATCHES] Win32 adjustments
I have applied the following patch with Magnus's guidance. It fixes
some Win32 problems introduced by my relative path installs.
It also removes the newline from psql for MinGW-only as posted by
Andrew. I added a mention to the Win32 todo list so we know to remove
it once we find the real cause.
--
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: src/backend/postmaster/postmaster.c
===
RCS file: /cvsroot/pgsql-server/src/backend/postmaster/postmaster.c,v
retrieving revision 1.388
diff -c -c -r1.388 postmaster.c
*** src/backend/postmaster/postmaster.c 17 May 2004 14:35:29 - 1.388
--- src/backend/postmaster/postmaster.c 18 May 2004 18:18:26 -
***
*** 295,302
#ifdef EXEC_BACKEND
- static char postgres_exec_path[MAXPGPATH];
-
#ifdef WIN32
pid_t win32_forkexec(const char* path, char *argv[]);
--- 295,300
***
*** 463,468
--- 461,471
IgnoreSystemIndexes(false);
+ if (find_my_exec(argv[0], my_exec_path) < 0)
+ ereport(FATAL,
+ (errmsg("%s: could not locate my own executable path",
+ progname)));
+
/*
* Options setup
*/
***
*** 690,702
(errmsg_internal("-")));
}
- /*
-* On some systems our dynloader code needs the executable's pathname.
-*/
- if (find_my_exec(argv[0], my_exec_path) < 0)
- ereport(FATAL,
- (errmsg("%s: could not locate my own executable path",
- progname)));
if (strlen(pkglib_path) == 0)
get_pkglib_path(my_exec_path, pkglib_path);
--- 693,698
Index: src/backend/tcop/postgres.c
===
RCS file: /cvsroot/pgsql-server/src/backend/tcop/postgres.c,v
retrieving revision 1.407
diff -c -c -r1.407 postgres.c
*** src/backend/tcop/postgres.c 17 May 2004 14:35:31 - 1.407
--- src/backend/tcop/postgres.c 18 May 2004 18:18:29 -
***
*** 2190,2195
--- 2190,2200
*/
EchoQuery = false;
+ if (strlen(my_exec_path) == 0 && find_my_exec(argv[0], my_exec_path) < 0)
+ ereport(FATAL,
+ (errmsg("%s: could not locate postgres executable",
+ argv[0])));
+
if (!IsUnderPostmaster)
{
InitializeGUCOptions();
***
*** 2549,2554
--- 2554,2562
}
Assert(DataDir);
+ if (strlen(pkglib_path) == 0)
+ get_pkglib_path(my_exec_path, pkglib_path);
+
/* Acquire configuration parameters */
if (IsUnderPostmaster)
{
***
*** 2645,2660
argv[0])));
}
- /*
-* On some systems our dynloader code needs the executable's pathname.
-*/
- if (strlen(my_exec_path) == 0 && find_my_exec(argv[0], my_exec_path) <
0)
- ereport(FATAL,
- (errmsg("%s: could not locate postgres
executable",
- argv[0])));
- if (strlen(pkglib_path) == 0)
- get_pkglib_path(my_exec_path, pkglib_path);
-
/*
* Validate we have been given a reasonable-looking DataDir (if
* under postmaster, assume postmaster did this already).
--- 2653,2658
Index: src/bin/psql/print.c
===
RCS file: /cvsroot/pgsql-server/src/bin/psql/print.c,v
retrieving revision 1.46
diff -c -c -r1.46 print.c
*** src/bin/psql/print.c24 Jan 2004 20:43:26 - 1.46
--- src/bin/psql/print.c18 May 2004 18:18:30 -
***
*** 388,394
--- 388,397
for (ptr = footers; *ptr; ptr++)
fprintf(fout, "%s\n", *ptr);
+ #ifndef __MINGW32__
+ /* for some reason MinGW outputs an extra newline, so this supresses it */
fputc('\n', fout);
+ #endif
/* clean up */
free(cell_w);
Index: src/port/exec.c
===
RCS file: /cvsroot/pgsql-server/src/port/exec.c,v
retrieving revision 1.7
diff -c -c -r1.7 exec.c
*** src/port/exec.c 18 May 2004 03:36:45 -
Re: [PATCHES] new aggregate functions v1
Agreed, these seem to be of general interest and have been requested in the past. I will clean up the docs a little. Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches I will try to apply it within the next 48 hours. --- Fabien COELHO wrote: > > Dear patchers, > > please find attached a small patch for adding new aggregate functions: > > (1) boolean-and and boolean-or aggregates named bool_and and bool_or. > they correspond to standard sql every and some/any aggregates. > they do not have the right name as there is a problem with > the standard and the parser for some/any. > > (2) bitwise integer aggregates named bit_and and bit_or for > int2, int4, int8 and bit types. They are not standard, > however they exist in other db (eg mysql), and I needed them > for some other stuff. > > > The patch adds: > > - 3 new functions for boolean aggregates in src/backed/utils/adt/bool.c, > src/include/utils/builtins.h and src/include/catalog/pg_proc.h > > - new aggregates declared in src/include/catalog/pg_proc.h and > src/include/catalog/pg_aggregate.h > > - some documentation and validation about these new aggregates. > > It also updates the catalog version. It validates for me. > > Have a nice day, > > -- > Fabien Coelho - [EMAIL PROTECTED] Content-Description: [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 5: Have you checked our extensive FAQ? > >http://www.postgresql.org/docs/faqs/FAQ.html -- 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 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] Timezone code, one more try
It seems this patch conflicts with Toms fix for Turkish locale. I had avoided going to a later snapshot to avoid the fallout from the relocateable install work Bruce did. I will pull a newer snapshot and update this patch so it applies to a more recent version. Should be done in a day or two max. Sorry about not checking this before I sent it. //Magnus > -Original Message- > From: Magnus Hagander > Sent: Monday, May 17, 2004 10:57 PM > To: [EMAIL PROTECTED] > Subject: [PATCHES] Timezone code, one more try > > Ok, here is another attempt at the timezone code. (let's > hope it's not too big to get through the patches list this > time) Changes from last > time: > > * Now used on all platforms, not just win32 (per request) > * Removes the part of the timezone library we don't use... > * Removes support for the system tz library, *requires* the > new builtin one (per request) > * As a bonus of this, removes a bunch of workarounds around > platform specific issues > * Attempts to pick up the OS timezone upon startup (will work > sometimes, fail sometimes, because there really is no API to > pick up the name of the current timezone..). Yes, this is > certainly somewhat hackish due to this.. > * Cleans out the timezone librarys use of K&R function > headers, changing them to ANSI > * As a bonus, "show timezone" will now work on an > installation that does not use the TZ env variable and does > not have timezone specified in postgresql.conf. Previously, > it just returned "unknown". > > > For the time being, the general APIs to the timezone > functions have not been changed. We might want to do that > eventually, but I figured getting it to work with the current > APIs is a good point to start. > The only exception to this is that pg_tzset() (replacement > for tzset) now returns a boolean value indicating if it has > successfully changed the timezone. That got rid of a lot of > workaround codes around the lack of failure indication. > > > The patch is very large, but the bulk of it is due to: > * The changing of the headers K&R -> ANSI > * The replacement of all "struct tm" to "struct pg_tm" (and > the same for the tz functions, but those are not as many) > * The replacement of all "include " with #include "pg_time.h" > > In doing this, I have also removed platform-specific > regression test outputs. Since they all use the lib now, it > should be fine. > > Attached files are: > timezone2.patch.gz - well, the patch. > pg_time.h - goes in src/include > strftime.c - goes in src/timezone > > The following files should be removed: > src/timezone/difftime.c > src/timezone/asctime.c > src/test/regress/expected/abstime-solaris-1947.out > src/test/regress/expected/horology-no-DST-before-1970.out > src/test/regress/expected/horology-solaris-1947.out > src/test/regress/expected/tinterval-solaris-1947.out > > > I have tested the patch, and it passes regression tests + > some other manual tests on Win32, Linux (Slackware 9) and > FreeBSD (5.2), all on > i386 hardware. I'm sure there will be *some* issues on others... > > > Comments? > > > //Magnus > <> > > ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] pg_ctl patch to integrate apache's rotatelogs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 |>logrotate rotates log files and hups the servers according to a |>configuration file. rotatelogs reads the log data on stdin and reopens |>a new output file once in a while. The first hunk of your patch was |>wrong, the rest seemed OK. | | | OK, just to confirm, I backed out the first attached patch, but kept the | rest, which is my second attached patch. This looks correct to me. | I am still confused how these errors remained in the documentation for | so long. Probably because non-syslog logging in a production environment is a very small niche. Which might, unfortunately, be a good argument against my proposed patch. Drew -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFAqhIGgfzn5SevSpoRAvizAJ0fZRI5o1FuERzUen2ufWwCsz/J2ACghQ7B agaY+YaC0LIVF/jNCk+QnmA= =Rsjl -END PGP SIGNATURE- ---(end of broadcast)--- TIP 8: explain analyze is your friend
[PATCHES] add build utilities in default install
Dear patchers,
Please find attached my first submission for installing all necessary
build files (makefile, scripts...) by default.
- for the old behavior, do a "make light-install"
- "make install" installs headers and other necessary files
such as scripts and makefiles, for postgresql extensions
to be build.
- these files are installed in "pg_config --insbuilddir"
the actual directory can be modified during configure with
"--with-insbuilddir=DIR" option. Default is LIBDIR/build
- the installation documentation is updated.
- I also added a "install-client-only" target so as to simplify the doc.
What is yet to be done:
- check that all necessary files are really there...
esp. wrt win32/cygwin
- provide an example makefile (script?) to build extensions, and install it!
I'm planning to do that later.
- check that the documentation is clear enough.
It validates (make check does perform a "make install").
I'm obviously ready to update the patch if necessary (missing files,
other default directories...).
Have a nice day,
--
Fabien Coelho - [EMAIL PROTECTED]*** ./GNUmakefile.in.orig Tue Apr 20 09:35:41 2004
--- ./GNUmakefile.inTue May 18 11:52:08 2004
***
*** 13,30
$(MAKE) -C src all
@echo "All of PostgreSQL successfully made. Ready to install."
! install:
$(MAKE) -C doc install
$(MAKE) -C src install
- @echo "PostgreSQL installation complete."
installdirs uninstall distprep:
$(MAKE) -C doc $@
$(MAKE) -C src $@
install-all-headers:
$(MAKE) -C src $@
# clean, distclean, etc should apply to contrib too, even though
# it's not built by default
clean:
--- 13,51
$(MAKE) -C src all
@echo "All of PostgreSQL successfully made. Ready to install."
! install: light-install install-all-headers install-config-files
! @echo "PostgreSQL installation complete."
!
! light-install:
$(MAKE) -C doc install
$(MAKE) -C src install
installdirs uninstall distprep:
$(MAKE) -C doc $@
$(MAKE) -C src $@
+ uninstall:
+ $(RM) $(DESTDIR)$(insbuilddir)/* $(DESTDIR)$(insbuilddir)/config/*
+
install-all-headers:
$(MAKE) -C src $@
+ install-config-files: installdirs
+ $(MAKE) -C src $@
+ $(INSTALL_DATA) config.status $(DESTDIR)$(insbuilddir)
+ $(INSTALL_DATA) config/install-sh $(DESTDIR)$(insbuilddir)/config
+ $(INSTALL_DATA) config/mkinstalldirs $(DESTDIR)$(insbuilddir)/config
+
+ installdirs:
+ $(mkinstalldirs) $(DESTDIR)$(insbuilddir)
+ $(mkinstalldirs) $(DESTDIR)$(insbuilddir)/config
+
+ install-client-only:
+ $(MAKE) -C src/bin install
+ $(MAKE) -C src/include install
+ $(MAKE) -C src/interfaces install
+ $(MAKE) -C doc install
+
# clean, distclean, etc should apply to contrib too, even though
# it's not built by default
clean:
*** ./configure.in.orig Mon May 17 14:00:03 2004
--- ./configure.in Tue May 18 12:02:38 2004
***
*** 128,133
--- 128,144
#
+ # Installation directory for build utilities
+ #
+ PGAC_ARG(with, insbuilddir,
+ [ --with-insbuilddir=DIR install build utilities in DIR [[LIBDIR/build]]],
+ [AC_MSG_ERROR([option --with-insbuilddir requires an argument])],
+ [AC_MSG_ERROR([option --without-insbuilddir does not apply])],
+ [insbuilddir=$withval],
+ [insbuilddir='${libdir}/build'])
+ AC_SUBST(insbuilddir)
+
+ #
# Add non-standard directories to the library search path
#
PGAC_ARG_REQ(with, libraries, [ --with-libraries=DIRS look for additional
libraries in DIRS],
*** ./doc/src/sgml/installation.sgml.orig Mon May 17 18:54:02 2004
--- ./doc/src/sgml/installation.sgmlTue May 18 11:42:02 2004
***
*** 589,594
--- 589,606
+
--with-insbuilddir=DIRECTORY
+
+
+Useful files for building PostgreSQL
+extensions, such as makefiles or scripts, will be installed in this
+directory.
+The default is LIBDIR/build
+
+
+
+
+
--with-docdir=DIRECTORY
--without-docdir
***
*** 1035,1064
! The standard installation provides only the header files needed for client
! application development. If you plan to do any server-side program
! development (such as custom functions or data types written in C),
! then you may want to install the entire PostgreSQL
! include tree into your target include directory. To do that, enter
! gmake install-all-headers
! This adds a megabyte or two to the installation footprint, and is only
! useful if you don't plan to keep the whole source tree around for
! reference. (If you do, you can just use the source's include
! directory when building server-side software.)
Client-only i
Re: [PATCHES] new aggregate functions v1
Dear Bruce, > Christopher Kings-Lynne wrote: > > What does this patch have to do with ACLs? Wasn't that Fabien's > > previous patch? > > I thought it was used to read them somehow. Yes, as for bit_* aggregates are concerned. However I still need them, and they also have been asked for in the past. This functionnality cost very little. Rejecting aclitem accessors just means that I'll have to install them with my package, hence the current discussion about providing all includes files and so by default. As for bool_and and bool_or are to provide standard functionnalities. I did not need them, but I saw them in the standard (every/any/some), thus I developed them next to the one I needed. -- Fabien Coelho - [EMAIL PROTECTED] ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
