[HACKERS] I know there are few hams on this list...
Ok, so this is off topic, but I know there are a few hams on this list. I'm wondering if any of them are going to Dayton this weekend? Probably better to contact me off list. Vince. -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 56K Nationwide Dialup from $16.00/mo at Pop4 Networking Online Campground Directoryhttp://www.camping-usa.com Online Giftshop Superstorehttp://www.cloudninegifts.com == ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Installation on SGI IRIX 6.5.10
Tom Lane wrote: That absolutely should NOT be necessary; there should be a proper extern declaration of strdup visible. Perhaps it should be added to include/port/irix5.h (cf port/nextstep.h). regards, tom lane Just to make sure, I tried compiling on another SGI. Everything went fine without any kludgy workarounds. It looks like somehow my compiler/OS has some problems. I'm upgrading to the latest OS version and compiler version. Thanks for the help. -Tony ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Configurable path to look up dynamic libraries
On Tue, May 15, 2001 at 05:53:36PM -0400, Bruce Momjian wrote: But, if I may editorialize a little myself, this is just indicative of a 'Fortress PostgreSQL' attitude that is easy to get into. 'We've always I have to admit I like the sound of 'Fortress PostgreSQL'. :-) Ye Olde PostgreSQL Shoppe The PostgreSQL of Giza Our Lady of PostgreSQL, Ascendant PostgreSQL International Airport PostgreSQL Galactica PostgreSQL's Tavern ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
AW: [HACKERS] pg_index.indislossy
Let's avoid removing things for the sake of removing them ... might be an old idea that, if someone takes the time to research, might prove useful ... Yea, there is actually some code attached to this vs. the others that had no code at all. Are we ever going to do partial indexes? I guess that is the question. The idea is very very good, and since there is an exaple implementation in pg 4 it should probably be possible to reimplement. (DB2 has this feature also) In real life, you would e.g. index a status column for rows, that need more work. create index deposit_status_index on deposit (status) where status 0; 99% of your rows would have status = 0 thus the index would be extremely efficient for all select statements that search for a specific status other than 0. Imho it would be a shame to give up that idea so easily. Andreas ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
AW: [HACKERS] pg_index.indislossy
One problem with keeping it is that interface coders are getting confused by some of the unused system table columns, assuming they mean something, when in fact they don't. Both ODBC and JDBC have had this problem that I fixed today. Imho the correct answer to this would be to implement the SQL standard system views, and make all interfaces use those. Andreas ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
AW: [HACKERS] pg_index.indislossy
Can someone tell me what we use indislossy for? Ok, so the interpretation of this field is: A match in the index needs to be reevaluated in the heap tuple data, since a match in the index does not necessarily mean, that the heap tuple matches. If the heap tuple data matches, the index must always match. A very typical example for such an index is a hash index. This might explain the fact, that the ODBC driver misinterpreted that field as meaning that the index is a hash. The field has nothing to do with partial index. Andreas ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Internet is putting lot of competition fire heat under Microsoft SQL Server
On Tue, May 15, 2001 at 07:19:01AM -0400, D'Arcy J.M. Cain wrote: Everybody is asking What is the equivalent of Linux in SQL databases ?? The answer is PostgreSQL RDBMS server. Oh please. Can we stop trying to tie everything to the current front runner. I mean, PostgreSQL uses the BSD style license, development It uses _the_ BSD license. is done under the BSD (cathedral) model and hey, it was invented at Berkeley in the first place. How is it the equivalent of Linux other than that it has the same price tag more or less. I'm not defending the comparison/analogy, just saying that it makes sense to lay people who have heard of Linux when they are explained about PostgreSQL. -Roberto -- +| http://fslc.usu.edu USU Free Software GNU/Linux Club |--+ Roberto Mello - Computer Science, USU - http://www.brasileiro.net http://www.sdl.usu.edu - Space Dynamics Lab, Developer Bad command or file name. Go sit in corner. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Configurable path to look up dynamic libraries
Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane writes: This is of little value unless the default is intelligently chosen. The default should be $PGLIB, IMHO (inserted from configure's data). This default has little value as well. Users don't generally put their loadable modules in the same directory as a PostgreSQL installation. That's a sweeping statement with little to back it up. How do you know that the usual procedure isn't to put things in $PGLIB? That's certainly what all our contrib packages do. Even more to the point, that's certainly where the PL call handler functions are. I will consider this feature utterly without value unless it allows the standard declaration of plpgsql_call_handler to become installation-independent, viz CREATE FUNCTION plpgsql_call_handler () RETURNS OPAQUE AS 'plpgsql' LANGUAGE 'C'; This also ties in somewhat with the fact that we have no default for PGDATA, on purpose. If we can have arbitrarily located data locations the system should not have a hard-wired in default for libraries (which are usually tied to particular databases in particular database clusters). I'd be willing to accept a default path that points to somewhere under $PGDATA, although I consider this rather less useful. Maybe we could agree on a compromise two-entry default path: $PGDATA/functions:$PGLIB? That would require some initdb-time shenanigans to set up, but if you want to do it... I also envision this to be used as part of dump/restore. pg_dump might have an option do not dump full path, and it would insert a 'set dynamic_library_path'. This would work like the previous case, really. What? What value would it have for pg_dump to do a set path operation? The dump script would be unlikely to actually invoke any of the functions it's loading. By the time anyone tries to use the functions, they'd be running in a different backend with a different path setting, namely the default for the installation. If we make this parameter postmaster start only then we really don't gain anything. We don't even gain the minimal expected convenience in pg_dump because you would force all modules to reside in a certain place where administrators would least like them to be. I fail to follow this claim also. The point as far as I'm concerned is that paths mentioned in CREATE FUNCTION ought to be relative to someplace that's installation-dependent. That way, when you dump out and reload a CREATE FUNCTION command, the declaration is still good, you just have to have put a copy of the function's shlib in the right place for the new installation. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] State of PL/Python build
Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane writes: I wonder whether people would like an option to statically link libperl.a and/or libpython.a into the Postgres backend proper? That would allow plperl/plpython to be used on platforms where this is an issue, without having to make a nonstandard build of perl/python. Not unless you also link in plperl/plpython itself or mess with -whole-archive type linker flags. The former is what I had in mind. Yes, it's ugly and it bloats the binary, but people would presumably only do this if they intended to use the language. So the bloat is somewhat illusory. And it's less ugly than having to build a nonstandard install of python or perl. I could even see people doing this on platforms where they didn't have to (because a non-PIC libpython or libperl could be included into a shared library plpython or plperl). It should give a performance advantage, which might be interesting to heavy users of those PLs. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Configurable path to look up dynamic libraries
Peter Eisentraut [EMAIL PROTECTED] writes: Perhaps it would be good to make the empty path component equivalent to $libdir, e.g., Hmm, that would work, and also avoid having to figure out how to stuff $PGLIB into postgresql.conf during initdb. Sold as far as I'm concerned ... regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Configurable path to look up dynamic libraries
Tom Lane [EMAIL PROTECTED] writes: Peter Eisentraut [EMAIL PROTECTED] writes: Perhaps it would be good to make the empty path component equivalent to $libdir, e.g., Hmm, that would work, and also avoid having to figure out how to stuff $PGLIB into postgresql.conf during initdb. While on the subject of postgresql conf... shouldn't it be in sysconfdir instead of the database directory? And there's no switch to the postmaster to tell it you've put it somewhere else either. -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Configurable path to look up dynamic libraries
[EMAIL PROTECTED] (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=) writes: Tom Lane [EMAIL PROTECTED] writes: [EMAIL PROTECTED] (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=) writes: You could search in a path... first sysconfdir, then datadir. Surely the other way around. Which could work as well - or just a switch to postmaster to tell it which file to use. I could live with a datadir-then-sysconfdir path search. (It should be datadir first, since the sysconfdir file would serve as a system-wide default for multiple postmasters.) Given that approach I see no real need for a postmaster switch. Possibly the same approach should apply to all the config files we currently store in datadir? There is a security issue here: stuff stored in datadir is not visible to random other users on the machine (since datadir is mode 700), but I would not expect sysconfdir to be mode 700. We'd need to think about the implications of allowing Postgres config files to be world-visible. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Configurable path to look up dynamic libraries
Tom Lane [EMAIL PROTECTED] writes: [EMAIL PROTECTED] (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=) writes: Tom Lane [EMAIL PROTECTED] writes: [EMAIL PROTECTED] (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=) writes: You could search in a path... first sysconfdir, then datadir. Surely the other way around. Which could work as well - or just a switch to postmaster to tell it which file to use. I could live with a datadir-then-sysconfdir path search. (It should be datadir first, since the sysconfdir file would serve as a system-wide default for multiple postmasters.) Given that approach I see no real need for a postmaster switch. Possibly the same approach should apply to all the config files we currently store in datadir? There is a security issue here: stuff stored in datadir is not visible to random other users on the machine (since datadir is mode 700), but I would not expect sysconfdir to be mode 700. It could be (the RPMs specify a sysconfdir of /etc/pgsql) We'd need to think about the implications of allowing Postgres config files to be world-visible. The files doesn't need to be visible to others... -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Configurable path to look up dynamic libraries
Tom Lane [EMAIL PROTECTED] writes: [EMAIL PROTECTED] (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=) writes: You could search in a path... first sysconfdir, then datadir. Surely the other way around. Which could work as well - or just a switch to postmaster to tell it which file to use. -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Configurable path to look up dynamic libraries
[EMAIL PROTECTED] (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=) writes: There is a security issue here: stuff stored in datadir is not visible to random other users on the machine (since datadir is mode 700), but I would not expect sysconfdir to be mode 700. It could be (the RPMs specify a sysconfdir of /etc/pgsql) The usual install procedure would probably leave sysconfdir owned by root, if one likes to install in such a way that the binaries are owned by root (ie make, su root, make install). I'd object to a setup that's insecure for people who aren't using RPMs. The real bottom line here, though, is that you haven't shown me any positive reason to move the config files out of datadir. They're not broken where they are; and arguably they *are* data. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Configurable path to look up dynamic libraries
[EMAIL PROTECTED] (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=) writes: The real bottom line here, though, is that you haven't shown me any positive reason to move the config files out of datadir. It conflicts with the FHS - AFAIK, the FHS is not designed to support multiple instances of unprivileged daemons. I'm not interested in forcing Postgres into that straitjacket ... regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Configurable path to look up dynamic libraries
Tom Lane [EMAIL PROTECTED] writes: [EMAIL PROTECTED] (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=) writes: There is a security issue here: stuff stored in datadir is not visible to random other users on the machine (since datadir is mode 700), but I would not expect sysconfdir to be mode 700. It could be (the RPMs specify a sysconfdir of /etc/pgsql) The usual install procedure would probably leave sysconfdir owned by root, if one likes to install in such a way that the binaries are owned by root (ie make, su root, make install). I'd object to a setup that's insecure for people who aren't using RPMs. So make the files unreadable, if so required. The real bottom line here, though, is that you haven't shown me any positive reason to move the config files out of datadir. It conflicts with the FHS - and no, I don't consider configuration files and data as an identical item. -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Configurable path to look up dynamic libraries
Lamar Owen [EMAIL PROTECTED] writes: Just because we've always done it one way does not that one way correct make. Sure. We're one component of a system -- and the PostgreSQL Group has done such a good job of being platform agnostic that the platform and systems issues are almost second-class citizens. Indeed, that I think is the underlying issue here. It's FHS compliant cuts no ice with people who don't run FHS-layout systems, and I don't want to improve FHS compliancy at the price of making life more difficult for others. (Likewise for other RPM installation issues, as you well know ;-)) I do think that the notion of a configure file path search (datadir then sysconfdir) is reasonable if the security and file protection issues can be ironed out. But that will require some thought about separating security-critical data from not-critical data. I think we ought to keep pg_hba.conf and subsidiary files (especially password files!) in datadir *only*. I'm not sure about the other config files; up to now no one's paid any attention to security issues for those files, knowing that they were all kept in the same place. We might need to reorganize their contents. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
