Re: [PATCHES] script binaries renaming
Am Mittwoch, 4. Juli 2007 17:04 schrieb Zdenek Kotala: I attach complete patch which renames following binaries createdb createlang createuser dropdb droplang dropuser clusterdb vacuumdb reindexdb I just want to say I dislike this idea. -- 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: [PATCHES] script binaries renaming
Am Donnerstag, 5. Juli 2007 06:59 schrieb Magnus Hagander: I'm also not sure we really should install copies on win32. Given how seldom these commands are actually used on windows But some people do use them, and they should have the same experience as on any other platform. I don't think disk space is really a concern, is it? -- 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: [PATCHES] Compile error with MSVC
Yoshiyuki Asaba wrote: Hi, From: Magnus Hagander [EMAIL PROTECTED] Subject: Re: [PATCHES] Compile error with MSVC Date: Thu, 05 Jul 2007 07:03:11 +0200 I tried to compile using Visual C++ 2005. But I got the following errors. .\src\backend\parser\keywords.c(22) : fatal error C1083: 'parser/parse.h': No such file or directory I saw src/tools/msvc/pgbison.bat. Why does it copy src/backend/parser/parser.h to src/include/parser directory? snip While your solution may be correct (I don't recall offhand how, but it doesn't seem off the chart), I don't see how it can help you in this case. Since pgbison would copy the file there, ISTM that pgbison must have filed. Did you not get a warning output from that one earlier in your build? If gram.c is older than gram.y, pgbison copy parse.h by custom build step. But it is newer, pgbison is skipped. I see the same problem in PostgreSQL 8.2.4. parse.h does not exist in src/include/parser directory. Oh, I see, you're building from the tarball, not from cvs. Now I see the problem. And yeah, your solution looks like the correct one. I'll take a look at the details and make sure it gets in there. //Magnus ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] script binaries renaming
On Fri, July 6, 2007 8:51 am, Peter Eisentraut wrote: Am Mittwoch, 4. Juli 2007 17:04 schrieb Zdenek Kotala: I attach complete patch which renames following binaries createdb createlang createuser dropdb droplang dropuser clusterdb vacuumdb reindexdb I just want to say I dislike this idea. This is almost as bad as Magnus agreeing with JD (!), but I agree with Peter :-). After years of typing the current names, changing them does seem somewhat annoying. Worse yet, pg_* is just awkward to type. /D ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] script binaries renaming
On Jul 6, 2007, at 5:53 , Dave Page wrote: On Fri, July 6, 2007 8:51 am, Peter Eisentraut wrote: Am Mittwoch, 4. Juli 2007 17:04 schrieb Zdenek Kotala: I attach complete patch which renames following binaries createdb createlang createuser dropdb droplang dropuser clusterdb vacuumdb reindexdb I just want to say I dislike this idea. This is almost as bad as Magnus agreeing with JD (!), but I agree with Peter :-). After years of typing the current names, changing them does seem somewhat annoying. Worse yet, pg_* is just awkward to type. While the change might be awkward, the names of these binaries really should be namespaced in some way. The current just too generic to be throwing into a bin/ directory in my opinion. Michael Glaesemann grzm seespotcode net ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Compile error with MSVC
Magnus Hagander wrote: Yoshiyuki Asaba wrote: Hi, From: Magnus Hagander [EMAIL PROTECTED] Subject: Re: [PATCHES] Compile error with MSVC Date: Thu, 05 Jul 2007 07:03:11 +0200 I tried to compile using Visual C++ 2005. But I got the following errors. .\src\backend\parser\keywords.c(22) : fatal error C1083: 'parser/parse.h': No such file or directory I saw src/tools/msvc/pgbison.bat. Why does it copy src/backend/parser/parser.h to src/include/parser directory? snip While your solution may be correct (I don't recall offhand how, but it doesn't seem off the chart), I don't see how it can help you in this case. Since pgbison would copy the file there, ISTM that pgbison must have filed. Did you not get a warning output from that one earlier in your build? If gram.c is older than gram.y, pgbison copy parse.h by custom build step. But it is newer, pgbison is skipped. I see the same problem in PostgreSQL 8.2.4. parse.h does not exist in src/include/parser directory. Oh, I see, you're building from the tarball, not from cvs. Now I see the problem. And yeah, your solution looks like the correct one. I'll take a look at the details and make sure it gets in there. Maybe what needs fixed is that the Makefile ought to copy the parse.h file to the include dir. Using src/backend/parser as an include dir strikes me as a bad idea. -- Alvaro Herrera http://www.amazon.com/gp/registry/CTMLCN8V17R4 Nunca se desea ardientemente lo que solo se desea por razón (F. Alexandre) ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] Compile error with MSVC
Alvaro Herrera wrote: Magnus Hagander wrote: Yoshiyuki Asaba wrote: Hi, From: Magnus Hagander [EMAIL PROTECTED] Subject: Re: [PATCHES] Compile error with MSVC Date: Thu, 05 Jul 2007 07:03:11 +0200 I tried to compile using Visual C++ 2005. But I got the following errors. .\src\backend\parser\keywords.c(22) : fatal error C1083: 'parser/parse.h': No such file or directory I saw src/tools/msvc/pgbison.bat. Why does it copy src/backend/parser/parser.h to src/include/parser directory? snip While your solution may be correct (I don't recall offhand how, but it doesn't seem off the chart), I don't see how it can help you in this case. Since pgbison would copy the file there, ISTM that pgbison must have filed. Did you not get a warning output from that one earlier in your build? If gram.c is older than gram.y, pgbison copy parse.h by custom build step. But it is newer, pgbison is skipped. I see the same problem in PostgreSQL 8.2.4. parse.h does not exist in src/include/parser directory. Oh, I see, you're building from the tarball, not from cvs. Now I see the problem. And yeah, your solution looks like the correct one. I'll take a look at the details and make sure it gets in there. Maybe what needs fixed is that the Makefile ought to copy the parse.h file to the include dir. Using src/backend/parser as an include dir strikes me as a bad idea. Well, the MSVC build is just emulating Unix regardless of if it's good or bad :-) Anyway. I'm not sure it matters enough to change it on Unix... It's not like it hasn't worked well for many years ;-) //Magnus ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] script binaries renaming
Michael Glaesemann wrote: On Jul 6, 2007, at 5:53 , Dave Page wrote: On Fri, July 6, 2007 8:51 am, Peter Eisentraut wrote: Am Mittwoch, 4. Juli 2007 17:04 schrieb Zdenek Kotala: I attach complete patch which renames following binaries createdb createlang createuser dropdb droplang dropuser clusterdb vacuumdb reindexdb I just want to say I dislike this idea. This is almost as bad as Magnus agreeing with JD (!), but I agree with Peter :-). After years of typing the current names, changing them does seem somewhat annoying. Worse yet, pg_* is just awkward to type. While the change might be awkward, the names of these binaries really should be namespaced in some way. The current just too generic to be throwing into a bin/ directory in my opinion. Of course I realize that I voted for the idea in the first place. I voted for it for consistency more than anything but as I think about it, it really is clunky and doesn't serve any real purpose. Joshua D. Drake Michael Glaesemann grzm seespotcode net ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org -- === 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 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] script binaries renaming
Michael Glaesemann wrote: On Jul 6, 2007, at 5:53 , Dave Page wrote: On Fri, July 6, 2007 8:51 am, Peter Eisentraut wrote: Am Mittwoch, 4. Juli 2007 17:04 schrieb Zdenek Kotala: I attach complete patch which renames following binaries createdb createlang createuser dropdb droplang dropuser clusterdb vacuumdb reindexdb I just want to say I dislike this idea. This is almost as bad as Magnus agreeing with JD (!), but I agree with Peter :-). After years of typing the current names, changing them does seem somewhat annoying. Worse yet, pg_* is just awkward to type. While the change might be awkward, the names of these binaries really should be namespaced in some way. The current just too generic to be throwing into a bin/ directory in my opinion. Why should they be name spaced? I see zero reason why that should be the case... apache_httpd? gnu_ls? The only obvious name spaced applications out there are in the G/K world of nome and de. Joshua D. Drake Michael Glaesemann grzm seespotcode net ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org -- === 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 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] script binaries renaming
On Jul 6, 2007, at 11:28 , Joshua D. Drake wrote: Why should they be name spaced? I see zero reason why that should be the case... apache_httpd? gnu_ls? Personally, I think that the Apache daemon *should* be named apached or something along those lines. Compare with postgres, pg_ctl, pg_dump, or pg_config. Albeit postgres is not consistent, they're all easily identifiable with PostgreSQL. In my opinion, postgres, pg_ctl, pg_ccmp, and pg_config are better names than, say, dbmsd, dbms_ctl, db_dump, and db_config. Also, we recently deprecated the use of postmaster (easily confused with mail systems) in favor of postgres. Looking at the binaries that are installed for 8.2: clusterdb createdb createlang createuser dropdb droplang dropuser ecpg initdb ipcclean pg_config pg_controldata pg_ctl pg_dump pg_dumpall pg_resetxlog pg_restore postgres postmaster - postgres psql reindexdb vacuumdb If these are all dumped into /usr/local/bin (as they sometimes are), many of them are not readily identifiable with PostgreSQL. Shouldn't they be? Compare with Subversion: svn svnadmin svndumpfileter svnlook svnserver svnsync svnversion I find these names much more consistent. Michael Glaesemann grzm seespotcode net ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] dblink connection security
Tom Lane wrote:
Here's a straw-man proposal that we could perhaps do for 8.3:
What about using the attached for 8.3, as well as earlier?
It simply does not allow the local database user to become someone else
on the libpq remote connection unless they are a superuser. As Tom
noted, a simple SECURITY DEFINER function created as a superuser could
allow backward compatible behavior.
CREATE OR REPLACE FUNCTION dblink_connect_u(connstr TEXT)
RETURNS TEXT AS $$
DECLARE passed TEXT;
BEGIN
SELECT dblink_connect(connstr) INTO passed;
RETURN passed;
END;
$$ LANGUAGE plpgsql SECURITY DEFINER;
contrib_regression=# \c - foo
You are now connected to database contrib_regression as user foo.
contrib_regression= select dblink_connect('dbname=contrib_regression');
ERROR: switching user not allowed
DETAIL: failed to connect local user foo as remote user postgres
HINT: only superuser may switch user name
contrib_regression= select dblink_connect_u('dbname=contrib_regression');
dblink_connect_u
--
OK
(1 row)
Comments?
Thanks,
Joe
Index: dblink.c
===
RCS file: /opt/src/cvs/pgsql/contrib/dblink/dblink.c,v
retrieving revision 1.63
diff -c -r1.63 dblink.c
*** dblink.c 6 Apr 2007 04:21:41 - 1.63
--- dblink.c 7 Jul 2007 04:39:49 -
***
*** 37,42
--- 37,43
#include libpq-fe.h
#include fmgr.h
#include funcapi.h
+ #include miscadmin.h
#include access/heapam.h
#include access/tupdesc.h
#include catalog/namespace.h
***
*** 230,235
--- 231,249
rconn = (remoteConn *) palloc(sizeof(remoteConn));
conn = PQconnectdb(connstr);
+ if (!superuser())
+ {
+ char *luser = PQuser(conn);
+ char *cuser = GetUserNameFromId(GetUserId());
+
+ if (strcmp(luser, cuser) != 0)
+ ereport(ERROR,
+ (errcode(ERRCODE_S_R_E_PROHIBITED_SQL_STATEMENT_ATTEMPTED),
+ errmsg(switching user not allowed),
+ errdetail(failed to connect local user \%s\ as remote user \%s\, cuser, luser),
+ errhint(only superuser may switch user name)));
+ }
+
MemoryContextSwitchTo(oldcontext);
if (PQstatus(conn) == CONNECTION_BAD)
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
