Re: [HACKERS] Trim the Fat (Was: Re: Open 7.3 items )
On Thu, 1 Aug 2002, Tom Lane wrote: Thomas Lockhart [EMAIL PROTECTED] writes: Until we have folks who are excited enough about it to plan it out and do the work, piecemeal rejection of components is not leading to a more solid product. I'm lukewarm about whether to actually do the split or not ... but for sure I agree with Thomas' point here. We need a plan and careful implementation, or a split-up will just make life worse. Stuff that is in the tree tends to get maintained in passing. For example, I've got some changes to contrib/dblink/ in my in-progress version of Chris' DROP COLUMN patch, because a grep for references to rel-rd_att turned it up. If dblink weren't in our CVS it'd have been broken by DROP COLUMN, and who knows whether we'd catch that during beta? I realize that Marc wasn't proposing splitting off any server-side code, but I still want to tread carefully about breaking up the codebase. Okay, well, the way I'm working it through right now, I'm doing it in such a way that unless you go mucking in the repository directly, it will be transparent to the coders, as well as to the distribution as a whole ... In fact, based on a comment that Thomas made in another email, I'll even fix up the whole 'cvs checkout pgsql' thing so that that goes back to its previous incarnation of pulling everything, instead of needing to do pgsql-all ... So, from the 'client side', y'all will still see everything as one big package, while from the 'server side', I'll have the seperate modules taht can be packaged independently ... Next, unless Peter knows how to do it already, I've gotta learn to make configure more intelligent, so that for all intents, the pieces look like one package when building, not just when coding ... ---(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] Trimming the Fat, Part Deux ...
On Wed, 31 Jul 2002, Thomas Lockhart wrote: ... *Eventually*, a simple checkout of 'pgsql' should result in a server only distribution that we can pull bits and pieces into transparently ... I'm still not quite sure where this is headed or why, but if nothing else pgsql could and should be the whole thing, and pgsql-server could be the server subset. Server-only makes sense for only some users, and nothing apparently makes sense for everyone. But we may as well have the old names do the old things... will make those changes in the morning ... ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Open 7.3 items
On Thu, 2002-08-01 at 02:05, Bruce Momjian wrote: Marc G. Fournier wrote: On Wed, 31 Jul 2002, Neil Conway wrote: On Wed, Jul 31, 2002 at 02:01:43AM -0300, Marc G. Fournier wrote: add in 'fix pg_hba.conf / password issues' to that too :) I doubt that will make 7.3 -- the proposals I've seen on this topic require some reasonably complex additions to the authentication system. We also still need to hash out which design we're going to implement. Given that it's pretty esoteric, I'd prefer this wait for 7.4 Then, the current changes *should* be removed, as we have no idea how many sites out there we are going to break without that functionality ... I know I personally have 200+ servers that will all break as soon as I move to v7.3 with it as is :( OK, I have thought about this. First, a possible solution would be to have a GUC variable that prepends the dbname to all username specifications, so the username becomes dbname.username. When I first read Marc's post about this I also thought that the users were partitioned by database, but further reading revealed that tis was not the case - actually they were partitioned by _a_group_of_databases_, as each of his virtual hosts accesses on _at_least_ one but possibly more databases using the same user (bruce ;). So we would need some sort of database groups that share the same users. We have to do something like this: real_user_name = mk_real_user_name(username,dbname) which uses some mapping table to find the real user that is trying to connect to the database. This name mangling should be done at connect time and kept out of database, where each users name should always be fully resolved ([EMAIL PROTECTED]). This may require raising the length of NAME type to be backwards compatible. Or we migth just add USEDOMAIN column to uniquely identify the user. so the above user would still have usename=bob but also usedomain=accounting.acme.com. --- Hannu ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Open 7.3 items
On Thu, 2002-08-01 at 06:48, Marc G. Fournier wrote: On Wed, 31 Jul 2002, Bruce Momjian wrote: One idea I had was to look for a colon in the username, and if I see one, I assume everything after the colon is a password. Would that work for you? That would definitely work ... but I *really* like your GUC idea ... it would allow ppl to change passwords using simple SQL statements remotely, which the old password stuff didn't allow for ... I think that the users domain should be kept separate from username if at all possible. This is how all modern authentication systems work. - Hannu ---(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] Open 7.3 items
-Original Message- From: Iavor Raytchev [mailto:[EMAIL PROTECTED]] Sent: 31 July 2002 22:12 To: pgsql-hackers Cc: pgaccess - developers Subject: Re: [HACKERS] Open 7.3 items psql is very definitely not ready, nor is pgaccess. I could not really trace who said this. To my understanding nobody is currently testing how pgaccess is dealing with 7.3 Am I wrong? If my experience with pgAdmin is anything to go on then you've got a *huge* amount of work to do for 7.3 if you haven't done anything yet. Regards, Dave. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Open 7.3 items
Bruce Momjian dijo: Here are the open items for 7.3. We have one more month to address them before beta. CLUSTER - ready? I'm just back. I'll have a look at the problem with the patch and resubmit. -- Alvaro Herrera (alvherre[a]atentus.com) Es filosofo el que disfruta con los enigmas (G. Coli) ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Open 7.3 items
NAMEDATALEN - disk/performance penalty for increase, 64, 128? FUNC_MAX_ARGS - disk/performance penalty for increase, 24, 32? At the moment I don't see a lot of solid evidence that increasing NAMEDATALEN has any performance penalty. Someone reported about a 10% slowdown on pgbench with NAMEDATALEN=128 ... but Neil Conway tried to reproduce the result, and got about a 10% *speedup*. Personally I think 10% is well within the noise spectrum for pgbench, and so it's difficult to claim that we have established any performance difference at all. I have not tried to measure FUNC_MAX_ARGS differences. Yes, we need someone to benchmark both the NAMEDATALEN and FUNC_MAX_ARGS to prove we are not causing performance problems. I think a valid NAMEDATALEN benchmark would need to use a lot of tables, like 1000-6000 with 10-100 columns each. The last bench was iirc done with pgbench that only uses a few tables. (The name type is fixed length) Andreas ---(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] Open 7.3 items
Le Mercredi 31 Juillet 2002 05:50, Bruce Momjian a écrit : Here are the open items for 7.3. We have one more month to address them before beta. Is CREATE OR REPLACE VIEW on the list? ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] getpid() function
On Tue, Jul 30, 2002 at 09:48:42PM -0400, Bruce Momjian wrote: OK, renamed to backend_pid() to match the libpq name. I was unsure about merging it into the stats stuff myself. setest= select backend_pid(); backend_pid - 12996 (1 row) Is there some common convention of names? Why not pg_backend_pid()? Karel -- Karel Zak [EMAIL PROTECTED] http://home.zf.jcu.cz/~zakkr/ C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Rules and Views
But the message I was replying to was a similar union query, and I was thinking that that person might be having a similar initial intuitive reaction, well, it looks kinda the same. I just wanted to note that you need to check this stuff with explain, rather than blindly assuming you know what's going on. I had a union all view, which is actually a quite different animal than a union view which needs to eliminate duplicates before further processing. Andreas ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Rules and Views
On Thu, 1 Aug 2002, Zeugswetter Andreas SB SD wrote: I had a union all view, which is actually a quite different animal than a union view which needs to eliminate duplicates before further processing. I had the same problem with UNION ALL. cjs -- Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---(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] Rules and Views
On Thu, 2002-08-01 at 12:29, Curt Sampson wrote: On Thu, 1 Aug 2002, Zeugswetter Andreas SB SD wrote: I had a union all view, which is actually a quite different animal than a union view which needs to eliminate duplicates before further processing. I had the same problem with UNION ALL. Could someone give an example where it is not safe to push the WHERE clause down to individual parts of UNION (or UNION ALL) wher these parts are simple (non-aggregate) queries? I can see that it has to be made into HAVING in subquery if UNION's subqueries are aggregate (GROUP BY) queries, but can anyone give an example where the meaning of the query changes for non-aggregate subqueries. --- Hannu ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] cvs checkout pgsql
... is once more 'normal' ... there are three modules right now setup: earthdistance libpqxx pgsql-server pgsql combines all three of the above to transparently give the equivalent of the whole distribution from its component parts ... ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Trim the Fat (Was: Re: Open 7.3 items )
Marc G. Fournier [EMAIL PROTECTED] writes: I realize that Marc wasn't proposing splitting off any server-side code, but I still want to tread carefully about breaking up the codebase. Okay, well, the way I'm working it through right now, I'm doing it in such a way that unless you go mucking in the repository directly, it will be transparent to the coders, as well as to the distribution as a whole ... In fact, based on a comment that Thomas made in another email, I'll even fix up the whole 'cvs checkout pgsql' thing so that that goes back to its previous incarnation of pulling everything, instead of needing to do pgsql-all ... Okay, that works for me --- that makes it just a packaging issue, and not something that will hide stuff from people who want to look through the whole tree. regards, tom lane ---(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] Trim the Fat (Was: Re: Open 7.3 items )
On Thu, 1 Aug 2002, Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] writes: I realize that Marc wasn't proposing splitting off any server-side code, but I still want to tread carefully about breaking up the codebase. Okay, well, the way I'm working it through right now, I'm doing it in such a way that unless you go mucking in the repository directly, it will be transparent to the coders, as well as to the distribution as a whole ... In fact, based on a comment that Thomas made in another email, I'll even fix up the whole 'cvs checkout pgsql' thing so that that goes back to its previous incarnation of pulling everything, instead of needing to do pgsql-all ... Okay, that works for me --- that makes it just a packaging issue, and not something that will hide stuff from people who want to look through the whole tree. Actually, it makes it a 'storage' issue on the CVS server itself, but makes creating various packages easier ... I've pop'd off an email to the libpqxx configure guys to get their standalone configure issues fixed (try running autogen.sh), after which I want to look into 'calling' the standalone configure from the global one if --enable-libpqxx is called (which we can later default to 'on' if that should become the default) ... ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Open 7.3 items
Hannu Krosing [EMAIL PROTECTED] writes: This name mangling should be done at connect time and kept out of database, where each users name should always be fully resolved ([EMAIL PROTECTED]). I really like Hannu's approach to this. It seems to solve Marc's problem with a very simple, easily understood, easily implemented feature. All we need is a postmaster configuration parameter that (when TRUE) causes the postmaster to convert the passed username into 'username@databasename' before looking it up in pg_shadow. (Actually, what I'd prefer it do is try first for username, and then username@databasename if plain username isn't found.) With this approach, we have an underlying mechanism that supports installation-wide usernames, same as before, but with the flip of a switch you can configure the system to support per-database usernames. It's not fancy, maybe, but it will get the job done with an appropriate amount of effort. We've had several proposals in this thread for complicated extensions to the user naming mechanism. I think that's overdesigning the feature, because we have *no* examples of real-world need for such things except for Marc's situation. Let's keep it simple until we see real use cases that can drive the design of something fancy. This may require raising the length of NAME type to be backwards compatible. Right, but we're planning to do that anyway. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Rules and Views
On 1 Aug 2002, Hannu Krosing wrote: On Thu, 2002-08-01 at 12:29, Curt Sampson wrote: On Thu, 1 Aug 2002, Zeugswetter Andreas SB SD wrote: I had a union all view, which is actually a quite different animal than a union view which needs to eliminate duplicates before further processing. I had the same problem with UNION ALL. Could someone give an example where it is not safe to push the WHERE clause down to individual parts of UNION (or UNION ALL) wher these parts are simple (non-aggregate) queries? For union, queries that want to do something like use a temporary sequence to act sort of like rownum and do row limiting. Admittedly that's already pretty much unspecified behavior, but it does change the behavior in the place of duplicate removal. In addition, I think using bits of the spec we don't completely support you can have the same issue with the undefined behavior of which duplicate is returned for values that aren't the same but are equal, for example where the duplicate removal is in one collation but the outer comparison has a different explicitly given one. I haven't come up with any useful examples, and not really any for union all, however. ---(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] getpid() function
On Thu, Aug 01, 2002 at 12:01:52PM +0200, Karel Zak wrote: Is there some common convention of names? No, there isn't (for example, pg_stat_backend_id() versus current_schema() -- or pg_get_viewdef() versus obj_description() ). Now that we have table functions, we might be using more built-in functions to provide information to the user -- so there will be an increasing need for some kind of naming convention for built-in functions. However, establishing a naming convention without breaking backwards compatibility might be tricky. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] getpid() function
On Thu, 2002-08-01 at 10:44, Neil Conway wrote: On Thu, Aug 01, 2002 at 12:01:52PM +0200, Karel Zak wrote: Is there some common convention of names? functions. However, establishing a naming convention without breaking backwards compatibility might be tricky. Supporting both names for a release with comments in the release notes stating the old names will disappear soon should be enough. Most of the time it'll be a simple replacement command. Providing a find -exec sed statement may help. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Rules and Views
On Thu, 1 Aug 2002, Stephan Szabo wrote:
On 1 Aug 2002, Hannu Krosing wrote:
On Thu, 2002-08-01 at 12:29, Curt Sampson wrote:
On Thu, 1 Aug 2002, Zeugswetter Andreas SB SD wrote:
I had a union all view, which is actually a quite different animal than
a union view which needs to eliminate duplicates before further processing.
I had the same problem with UNION ALL.
Could someone give an example where it is not safe to push the WHERE
clause down to individual parts of UNION (or UNION ALL) wher these parts
are simple (non-aggregate) queries?
For union, queries that want to do something like use a temporary
sequence to act sort of like rownum and do row limiting. Admittedly
that's already pretty much unspecified behavior, but it does change
the behavior in the place of duplicate removal. In addition, I think
using bits of the spec we don't completely support you can have the
same issue with the undefined behavior of which duplicate is returned
for values that aren't the same but are equal, for example where the
duplicate removal is in one collation but the outer comparison has
a different explicitly given one.
Replying to myself, you can do this right now with char columns if you
just push the conditions down blindly, something like:
create table t1(a char(5));
create table t2(a char(6));
insert into t1 values ('a');
insert into t2 values ('a');
select * from (select * from t2 union select * from t1) as f where
a::text='a';
select * from (select * from t2 where a::text='a' union
select * from t1 where a::text='a') as f;
The first select gives no rows, the second gives one. We'd have
to transform the second where clause to something like
cast(a as char(6))::text='a' in order to get the same effect
I think.
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] getpid() function
On Thu, Aug 01, 2002 at 10:44:23AM -0400, Neil Conway wrote: On Thu, Aug 01, 2002 at 12:01:52PM +0200, Karel Zak wrote: Is there some common convention of names? No, there isn't (for example, pg_stat_backend_id() versus I know -- for this I asked. IMHO for large project like PostgreSQL it's important. It's not good if there is possible speculate about name of new function. It must be unmistakable -- for this is needful make some convension. If somebody add new function and it's released, it's in the PostgreSQL almost forever. current_schema() -- or pg_get_viewdef() versus obj_description() ). Now that we have table functions, we might be using more built-in functions to provide information to the user -- so there will be an increasing need for some kind of naming convention for built-in functions. However, establishing a naming convention without breaking backwards compatibility might be tricky. Yes, but we can try be clean for new stuff. Karel -- Karel Zak [EMAIL PROTECTED] http://home.zf.jcu.cz/~zakkr/ C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Trimming the Fat, Part Deux ...
On Wednesday 31 July 2002 09:38 pm, Marc G. Fournier wrote: Okay ... since this is pretty much going to be 'one camp for, one camp against' without anything to really back up either camps perspectives / arguments, I did some research on CVS in order to find a nice, effective middle ground ... and it actually works quite sweet ... MAn, did I ever pick a bad day to be offline for a whole day. :-) If anyone cares to look, or for that matter cares at all, something similar is already being done in the binary RPMs. I have split, sliced, and diced this distribution for over three years. So, let me share some of the experiences learned from that exercise. Now comes the 'tricky part, which I'm hoping someone like Peter might know how to do ... I know there is a way of writing configure to 'run configure' in sub projects .. for instance, with libpqxx ... at the top level of pgsql, one could type: ./configure --enable-libpqxx I like this idea, up to an extent. I guess it boils down to this: 1.) What is the minimum build environment necessary to build anything in the source distribution; 2.) What degree of granularity is desired; 3.) We must not assume the presence of a full source tree to build _anything_, only the minimum build system, which can then handle everything else as a module. Then I could much more easily package a 'postgresql-devel' package that would allow, for instance, PostGIS to be built as a server module without having to have the entire source distribution tree in place (which is currently required). As PostGIS is a separately developed and distributed module, it seems reasonable that it should be buildable without the full source tree in place. As to getting rid of bloat, I'm all for splitting out contrib modules, client libraries, and the like into separate projects. If the build system is a unit, and is not dependent upon the server or libpq source code, then it is easier and more consistent to just require it to be in place to build ANY contrib or client module. We're too big and too spread out. It was said (by Andrew) that we're hard to install -- why is that? Is it possible that it is _because_ of the number of pieces we include? And the sooner our very old perl client goes away, the better I like it. It is a good client, don't get me wrong: but DBD:Pg is the standard now. But, if you are an RPM user, you can already just download the pieces for a minimal client-side system. And you have been able to do so for right at three years, give or take. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Trimming the Fat, Part Deux ...
And the sooner our very old perl client goes away, the better I like it. It is a good client, don't get me wrong: but DBD:Pg is the standard now. This may sound like a dumb question, but DBD::Pg == DBI right ? not pg.pm I code perl about 25 hours a week, and DBI has never failed me yet. Jeff. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Trimming the Fat, Part Deux ...
On Thursday 01 August 2002 12:05 pm, Jeff MacDonald wrote: And the sooner our very old perl client goes away, the better I like it. It is a good client, don't get me wrong: but DBD:Pg is the standard now. This may sound like a dumb question, but DBD::Pg == DBI right ? not pg.pm Right. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] WAL file location
On Wed, Jul 31, 2002 at 11:20:35PM -0400, Bruce Momjian wrote: I am wondering why we even want to specify the WAL location anywhere except as a flag to initdb. If you specify a location at initdb time, it creates the /xlog directory, then symlinks it into /data. I thought the whole point of it was to make it easy to move WAL. Which is certainly a Good Thing. A -- Andrew Sullivan 87 Mowat Avenue Liberty RMS Toronto, Ontario Canada [EMAIL PROTECTED] M6K 3E3 +1 416 646 3304 x110 ---(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] cvs checkout pgsql
On Thu, 1 Aug 2002, Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] writes: ... is once more 'normal' ... Uh, it's completely broken as far as I can tell. $ pwd /home/postgres/pgsql/src/bin/pg_dump $ cvs status cvs server: Examining . cvs server: failed to create lock directory for `/cvsroot/pgsql/src/bin/pg_dump' (/cvsroot/pgsql/src/bin/pg_dump/#cvs.lock): No such file or directory cvs server: failed to obtain dir lock in repository `/cvsroot/pgsql/src/bin/pg_dump' cvs [server aborted]: read lock failed - giving up $ Also, http://developer.postgresql.org/cvsweb.cgi/pgsql/ isn't working. This makes it a little difficult to get any work done :-( I made a large change this morning based on a comment by Thomas ... the way I *had* it was to get the whole thing, you had to checkout pgsql-all ... Thomas suggested leaving it as pgsql, with pgsql-server being 'the base', but in order to do that, I had to move the pgsql repository to pgsql-server, since otherwise modules makes it recursive on my ... its a 'one time only change', but it requires a fresh checkout to get the patches in properly ... same thing that I explained yesterday about how you'll get a 'No such file or directory' is you tried to update, say, libpqxx, since its path is no longer /cvsroot/pgsql/src/interfaces/libpqxx, but is /cvsroot/interfaces/libpqxx ... the fact that its different modules is transparent to the programmer *unless*, of course, its already checked out at the tiem :( Script started on Thu Aug 1 15:15:48 2002 setenv CVSROOT /cvsroot cvs -q checkout -P pgsql U pgsql/COPYRIGHT U pgsql/GNUmakefile.in U pgsql/HISTORY U pgsql/INSTALL alot of lines deleted U pgsql/src/interfaces/libpqxx/test/test5.cxx U pgsql/src/interfaces/libpqxx/test/test6.cxx U pgsql/src/interfaces/libpqxx/test/test7.cxx U pgsql/src/interfaces/libpqxx/test/test8.cxx U pgsql/src/interfaces/libpqxx/test/test9.cxx cd pgsql/src/bin/pg_dump cvs s cvs status cvs status: Examining . === File: Makefile Status: Up-to-date Working revision:1.36Sat Jul 27 20:10:05 2002 Repository revision: 1.36/cvsroot/pgsql-server/src/bin/pg_dump/Makefile,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) === File: READMEStatus: Up-to-date Working revision:1.5 Fri Jul 21 11:40:08 2000 Repository revision: 1.5 /cvsroot/pgsql-server/src/bin/pg_dump/README,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) alot more lines deleted === File: zh_CN.po Status: Up-to-date Working revision:1.5 Mon Dec 10 18:45:57 2001 Repository revision: 1.5 /cvsroot/pgsql-server/src/bin/pg_dump/zh_CN.po,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) === File: zh_TW.po Status: Up-to-date Working revision:1.3 Thu Nov 29 18:59:28 2001 Repository revision: 1.3 /cvsroot/pgsql-server/src/bin/pg_dump/zh_TW.po,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) exit exit Script done on Thu Aug 1 15:16:51 2002 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] cvs checkout pgsql
On Thu, 1 Aug 2002, Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] writes: ... is once more 'normal' ... Uh, it's completely broken as far as I can tell. $ pwd /home/postgres/pgsql/src/bin/pg_dump $ cvs status cvs server: Examining . cvs server: failed to create lock directory for `/cvsroot/pgsql/src/bin/pg_dump' (/cvsroot/pgsql/src/bin/pg_dump/#cvs.lock): No such file or directory cvs server: failed to obtain dir lock in repository `/cvsroot/pgsql/src/bin/pg_dump' cvs [server aborted]: read lock failed - giving up $ Also, http://developer.postgresql.org/cvsweb.cgi/pgsql/ isn't working. This makes it a little difficult to get any work done :-( What'r you typin about? It works fine. Ok, ok.. It does *NOW*. :) There's probably still stuff that's broke that I haven't discovered yet. 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] cvs checkout pgsql
On Thu, 2002-08-01 at 15:33, Vince Vielhaber wrote: On Thu, 1 Aug 2002, Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] writes: ... is once more 'normal' ... Uh, it's completely broken as far as I can tell. $ pwd /home/postgres/pgsql/src/bin/pg_dump $ cvs status cvs server: Examining . cvs server: failed to create lock directory for `/cvsroot/pgsql/src/bin/pg_dump' (/cvsroot/pgsql/src/bin/pg_dump/#cvs.lock): No such file or directory cvs server: failed to obtain dir lock in repository `/cvsroot/pgsql/src/bin/pg_dump' cvs [server aborted]: read lock failed - giving up $ Also, http://developer.postgresql.org/cvsweb.cgi/pgsql/ isn't working. This makes it a little difficult to get any work done :-( What'r you typin about? It works fine. Ok, ok.. It does *NOW*. :) There's probably still stuff that's broke that I haven't discovered yet. Well, of course that specific URL doesn't work because it's actually pgsql-server. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] cvs checkout pgsql
Rod Taylor [EMAIL PROTECTED] writes: Also, http://developer.postgresql.org/cvsweb.cgi/pgsql/ isn't working. What'r you typin about? It works fine. Ok, ok.. It does *NOW*. :) Well, of course that specific URL doesn't work because it's actually pgsql-server. Well, it did work before, and I'd really like it to work again. I do not want to think about how Marc's broken apart the distribution when I'm looking at my local tree, and I don't want to think about it when I'm looking at cvsweb either. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Module Portability
All this talk of modularity reminds me of a pet peeve: doing dump/restore upgrades when your databases include extension functions is highly clunky, because extension functions include the fully qualified path to the linking library. So, for example create function geometry_in(opaque) RETURNS GEOMETRY AS '/opt/pgsql72/lib/contrib/libpostgis.so.0.7' LANGUAGE 'c' with (isstrict); If I do a pg_dumpall on an old database and try to pipe into a new database, things can get messy pretty fast. It would be nice if pgsql had a 'default library location' which it tried to load linking libraries from, in much the same way apache uses libexec. Then my definition could just be: create function geometry_in(opaque) RETURNS GEOMETRY AS 'libpostgis.so.0.7' LANGUAGE 'c' with (isstrict); Which would be alot more portable across installations. I mean, right now I can render my database inoperative just by moving my executable installation tree to a new path. Nice. -- __ / | Paul Ramsey | Refractions Research | Email: [EMAIL PROTECTED] | Phone: (250) 885-0632 \_ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] cvs checkout pgsql
On 1 Aug 2002, Rod Taylor wrote: On Thu, 2002-08-01 at 15:33, Vince Vielhaber wrote: On Thu, 1 Aug 2002, Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] writes: ... is once more 'normal' ... Uh, it's completely broken as far as I can tell. $ pwd /home/postgres/pgsql/src/bin/pg_dump $ cvs status cvs server: Examining . cvs server: failed to create lock directory for `/cvsroot/pgsql/src/bin/pg_dump' (/cvsroot/pgsql/src/bin/pg_dump/#cvs.lock): No such file or directory cvs server: failed to obtain dir lock in repository `/cvsroot/pgsql/src/bin/pg_dump' cvs [server aborted]: read lock failed - giving up $ Also, http://developer.postgresql.org/cvsweb.cgi/pgsql/ isn't working. This makes it a little difficult to get any work done :-( What'r you typin about? It works fine. Ok, ok.. It does *NOW*. :) There's probably still stuff that's broke that I haven't discovered yet. Well, of course that specific URL doesn't work because it's actually pgsql-server. But the developer's web page is updated with the new info. 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] cvs checkout pgsql
On Thu, 1 Aug 2002, Tom Lane wrote: Rod Taylor [EMAIL PROTECTED] writes: Also, http://developer.postgresql.org/cvsweb.cgi/pgsql/ isn't working. What'r you typin about? It works fine. Ok, ok.. It does *NOW*. :) Well, of course that specific URL doesn't work because it's actually pgsql-server. Well, it did work before, and I'd really like it to work again. I do not want to think about how Marc's broken apart the distribution when I'm looking at my local tree, and I don't want to think about it when I'm looking at cvsweb either. You don't have to think about anything ... god, does *nobody* read what they are replying to?? if you do a cvs checkout of pgsql, you will get exactly what you are used to ... you can update, commit, look at status, look at logs, etc ... cvs itself is setup to handle pulling in and placing the required modules when you do the checkout of pgsql ... I could move docs into $CVSROOT/this/is/a/stupid/directory/structure/docs and except for the fact that you already have a copy checked out pointing to the old path, a fresh checkout would still place that in pgsql/docs, where you've grown used to it being ... ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] CVS server problem!
Seems the CVS server is not working correctly. I just deleted my CVS tree and did a fresh checkout of the pgsql module. Everything seemingly went well. After the check out completed, I did: [gcope@mouse pgsql]$ ./configure --with-tcl --with-java --with-python --with-perl checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking which template to use... linux checking whether to build with 64-bit integer date/time support... no checking whether to build with recode support... no checking whether NLS is wanted... no checking for default port number... 5432 checking for default soft limit on number of connections... 32 checking for gcc... gcc checking for C compiler default output... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes ./configure: ./src/template/linux: No such file or directory So, I did, ./configure which yields the same result. So, thinking maybe I just had a poorly timed checkout, I did an update. Doing so, looks like this: [gcope@mouse pgsql]$ cvs -z3 update -dP ? config.log cvs server: Updating . cvs server: Updating ChangeLogs cvs server: Updating MIGRATION cvs server: Updating config . . . src/backend/utils/mb/conversion_procs/utf8_and_iso8859_1 cvs server: Updating src/backend/utils/mb/conversion_procs/utf8_and_johab cvs server: Updating src/backend/utils/mb/conversion_procs/utf8_and_sjis cvs server: cannot open directory /projects/cvsroot/pgsql/src/backend/utils/mb/conversion_procs/utf8_and_sjis: No such file or directory cvs server: skipping directory src/backend/utils/mb/conversion_procs/utf8_and_sjis cvs server: Updating src/backend/utils/mb/conversion_procs/utf8_and_tcvn cvs server: cannot open directory /projects/cvsroot/pgsql/src/backend/utils/mb/conversion_procs/utf8_and_tcvn: No such file or directory cvs server: skipping directory src/backend/utils/mb/conversion_procs/utf8_and_tcvn cvs server: Updating src/backend/utils/mb/conversion_procs/utf8_and_uhc cvs server: cannot open directory /projects/cvsroot/pgsql/src/backend/utils/mb/conversion_procs/utf8_and_uhc: No such file or directory cvs server: skipping directory src/backend/utils/mb/conversion_procs/utf8_and_uhc cvs server: Updating src/backend/utils/misc cvs server: cannot open directory /projects/cvsroot/pgsql/src/backend/utils/misc: No such file or directory cvs server: skipping directory src/backend/utils/misc cvs server: Updating src/backend/utils/mmgr cvs server: cannot open directory /projects/cvsroot/pgsql/src/backend/utils/mmgr: No such file or directory cvs server: skipping directory src/backend/utils/mmgr cvs server: Updating src/backend/utils/sort cvs server: cannot open directory /projects/cvsroot/pgsql/src/backend/utils/sort: No such file or directory cvs server: skipping directory src/backend/utils/sort cvs server: Updating src/backend/utils/time cvs server: cannot open directory /projects/cvsroot/pgsql/src/backend/utils/time: No such file or directory cvs server: skipping directory src/backend/utils/time cvs server: Updating src/bin cvs server: cannot open directory /projects/cvsroot/pgsql/src/bin: No such file or directory cvs server: skipping directory src/bin So, I'm fairly sure something is awry. Greg On Mon, 2002-07-29 at 20:51, Tatsuo Ishii wrote: Can anyone fix this? $ cvs up can't create temporary directory /tmp/cvs-serv40296 No space left on device -- Tatsuo Ishii ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org signature.asc Description: This is a digitally signed message part
Re: [HACKERS] Trimming the Fat, Part Deux ...
Someone said earlier cvsup would have problems but the anonymous cvs would work fine. Well I've just had a weirdness reconfiguring and rebuilding my few weeks old 7.3dev tree and so deleted it and tried using the anoncvs to get pgsql. Running configure gives me the error: ./configure: ./src/template/linux: No such file or directory and all ./src contains is: total 44 drwxr-xr-x2 software software 4096 Aug 1 23:27 CVS -rw-r--r--1 software software 119 Jul 30 1999 DEVELOPERS -rw-r--r--1 software software 1039 Jul 30 18:47 Makefile -rw-r--r--1 software software13288 Jul 27 21:10 Makefile.global.in -rw-r--r--1 software software10853 Jul 27 21:10 Makefile.shlib drwxr-xr-x 23 software software 4096 Aug 1 23:27 backend -- Nigel J. Andrews Director --- Logictree Systems Limited Computer Consultants ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] cvs checkout pgsql
Looks like I replied to the wrong thread...here's a repeat... Seems the CVS server is not working correctly. I just deleted my CVS tree and did a fresh checkout of the pgsql module. Everything seemingly went well. After the check out completed, I did: [gcope@mouse pgsql]$ ./configure --with-tcl --with-java --with-python --with-perl checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking which template to use... linux checking whether to build with 64-bit integer date/time support... no checking whether to build with recode support... no checking whether NLS is wanted... no checking for default port number... 5432 checking for default soft limit on number of connections... 32 checking for gcc... gcc checking for C compiler default output... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes ./configure: ./src/template/linux: No such file or directory So, I did, ./configure which yields the same result. So, thinking maybe I just had a poorly timed checkout, I did an update. Doing so, looks like this: [gcope@mouse pgsql]$ cvs -z3 update -dP ? config.log cvs server: Updating . cvs server: Updating ChangeLogs cvs server: Updating MIGRATION cvs server: Updating config . . . src/backend/utils/mb/conversion_procs/utf8_and_iso8859_1 cvs server: Updating src/backend/utils/mb/conversion_procs/utf8_and_johab cvs server: Updating src/backend/utils/mb/conversion_procs/utf8_and_sjis cvs server: cannot open directory /projects/cvsroot/pgsql/src/backend/utils/mb/conversion_procs/utf8_and_sjis: No such file or directory cvs server: skipping directory src/backend/utils/mb/conversion_procs/utf8_and_sjis cvs server: Updating src/backend/utils/mb/conversion_procs/utf8_and_tcvn cvs server: cannot open directory /projects/cvsroot/pgsql/src/backend/utils/mb/conversion_procs/utf8_and_tcvn: No such file or directory cvs server: skipping directory src/backend/utils/mb/conversion_procs/utf8_and_tcvn cvs server: Updating src/backend/utils/mb/conversion_procs/utf8_and_uhc cvs server: cannot open directory /projects/cvsroot/pgsql/src/backend/utils/mb/conversion_procs/utf8_and_uhc: No such file or directory cvs server: skipping directory src/backend/utils/mb/conversion_procs/utf8_and_uhc cvs server: Updating src/backend/utils/misc cvs server: cannot open directory /projects/cvsroot/pgsql/src/backend/utils/misc: No such file or directory cvs server: skipping directory src/backend/utils/misc cvs server: Updating src/backend/utils/mmgr cvs server: cannot open directory /projects/cvsroot/pgsql/src/backend/utils/mmgr: No such file or directory cvs server: skipping directory src/backend/utils/mmgr cvs server: Updating src/backend/utils/sort cvs server: cannot open directory /projects/cvsroot/pgsql/src/backend/utils/sort: No such file or directory cvs server: skipping directory src/backend/utils/sort cvs server: Updating src/backend/utils/time cvs server: cannot open directory /projects/cvsroot/pgsql/src/backend/utils/time: No such file or directory cvs server: skipping directory src/backend/utils/time cvs server: Updating src/bin cvs server: cannot open directory /projects/cvsroot/pgsql/src/bin: No such file or directory cvs server: skipping directory src/bin So, I'm fairly sure something is awry. Greg Unrelated quote: I could move docs into $CVSROOT/this/is/a/stupid/directory/structure/docs and except for the fact that you already have a copy checked out pointing to the old path, a fresh checkout would still place that in pgsql/docs, where you've grown used to it being ... You do realize that by moving modules outside of the base project, you're forcing more work for the masses. That is, if you plan to have /doc, /pgsql-server, /contrib, etc, people will now have to create a new .../pgsql directory locally which means, locally, people will have .../pgsql/pgsql-server, .../pgsql/contrib, etc...why force onto the developer what CVS should already be doing it. I don't know about you guys, but when I check out pgsql, I certainly expect everything to be there. If that's not what I want, then I should be more explicate in what I pick for checkout. Just some food for thought...this is a common peeve of mine when people decide they need to restructure their repository...seems like this is always done and almost always a poor choice that isn't realized until it's all done and over with. Greg signature.asc Description: This is a digitally signed message part
Re: [HACKERS] CVS server problem!
Should be fixed now ... I found a rsync.core file, so it looks like the changes may have been more extensive then rsync could handle ... just ran it manually (or, rather, am running as I type this), so by the time you receive, a checkout should grab the right structures ... Let me know if it works now for you ... On 1 Aug 2002, Greg Copeland wrote: Seems the CVS server is not working correctly. I just deleted my CVS tree and did a fresh checkout of the pgsql module. Everything seemingly went well. After the check out completed, I did: [gcope@mouse pgsql]$ ./configure --with-tcl --with-java --with-python --with-perl checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking which template to use... linux checking whether to build with 64-bit integer date/time support... no checking whether to build with recode support... no checking whether NLS is wanted... no checking for default port number... 5432 checking for default soft limit on number of connections... 32 checking for gcc... gcc checking for C compiler default output... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes ./configure: ./src/template/linux: No such file or directory So, I did, ./configure which yields the same result. So, thinking maybe I just had a poorly timed checkout, I did an update. Doing so, looks like this: [gcope@mouse pgsql]$ cvs -z3 update -dP ? config.log cvs server: Updating . cvs server: Updating ChangeLogs cvs server: Updating MIGRATION cvs server: Updating config . . . src/backend/utils/mb/conversion_procs/utf8_and_iso8859_1 cvs server: Updating src/backend/utils/mb/conversion_procs/utf8_and_johab cvs server: Updating src/backend/utils/mb/conversion_procs/utf8_and_sjis cvs server: cannot open directory /projects/cvsroot/pgsql/src/backend/utils/mb/conversion_procs/utf8_and_sjis: No such file or directory cvs server: skipping directory src/backend/utils/mb/conversion_procs/utf8_and_sjis cvs server: Updating src/backend/utils/mb/conversion_procs/utf8_and_tcvn cvs server: cannot open directory /projects/cvsroot/pgsql/src/backend/utils/mb/conversion_procs/utf8_and_tcvn: No such file or directory cvs server: skipping directory src/backend/utils/mb/conversion_procs/utf8_and_tcvn cvs server: Updating src/backend/utils/mb/conversion_procs/utf8_and_uhc cvs server: cannot open directory /projects/cvsroot/pgsql/src/backend/utils/mb/conversion_procs/utf8_and_uhc: No such file or directory cvs server: skipping directory src/backend/utils/mb/conversion_procs/utf8_and_uhc cvs server: Updating src/backend/utils/misc cvs server: cannot open directory /projects/cvsroot/pgsql/src/backend/utils/misc: No such file or directory cvs server: skipping directory src/backend/utils/misc cvs server: Updating src/backend/utils/mmgr cvs server: cannot open directory /projects/cvsroot/pgsql/src/backend/utils/mmgr: No such file or directory cvs server: skipping directory src/backend/utils/mmgr cvs server: Updating src/backend/utils/sort cvs server: cannot open directory /projects/cvsroot/pgsql/src/backend/utils/sort: No such file or directory cvs server: skipping directory src/backend/utils/sort cvs server: Updating src/backend/utils/time cvs server: cannot open directory /projects/cvsroot/pgsql/src/backend/utils/time: No such file or directory cvs server: skipping directory src/backend/utils/time cvs server: Updating src/bin cvs server: cannot open directory /projects/cvsroot/pgsql/src/bin: No such file or directory cvs server: skipping directory src/bin So, I'm fairly sure something is awry. Greg On Mon, 2002-07-29 at 20:51, Tatsuo Ishii wrote: Can anyone fix this? $ cvs up can't create temporary directory /tmp/cvs-serv40296 No space left on device -- Tatsuo Ishii ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Rules and Views
Stephan Szabo [EMAIL PROTECTED] writes: For union, queries that want to do something like use a temporary sequence to act sort of like rownum and do row limiting. Admittedly that's already pretty much unspecified behavior, but it does change the behavior in the place of duplicate removal. In addition, I think using bits of the spec we don't completely support you can have the same issue with the undefined behavior of which duplicate is returned for values that aren't the same but are equal, for example where the duplicate removal is in one collation but the outer comparison has a different explicitly given one. Hmm. I think this consideration boils down to whether the WHERE clause can give different results for rows that appear equal under the rules of UNION/EXCEPT/INTERSECT. If it gives the same result for any two such rows, then it's safe to push down; otherwise not. It's not too difficult to come up with examples. I invite you to play with select z,length(z) from (select 'abc'::char(7) as z intersect select 'abc'::char(8) as z) ss; and contemplate the effects of pushing down a qual involving length(z). Whether this particular case is very important in the real world is hard to say. But there might be more-important cases out there. And yet, I think we can do it anyway. The score card looks like this to me: UNION ALL: always safe to push down, since the rows will be passed independently to the outer WHERE anyway. UNION: it's unspecified which of a set of equal rows will be returned, and therefore the behavior would be unspecified anyway if the outer WHERE can distinguish the rows - you might get 1 row of the set out or none. If we push down, then we create a situation where the returned row will always be one that passes the outer WHERE, but that is a legal behavior. INTERSECT: again it's unspecified which of a set of equal rows will be returned, and so you might get 1 row out or none. If we push down then it's still unspecified whether you get a row out (example: if the outer WHERE will pass only for rows of the left table and not the right, then push down will result in no rows of the equal set being emitted, but that's a legal behavior). INTERSECT ALL: if a set of equal rows contains M rows from the left table and N from the right table, you're supposed to get min(M,N) rows of the set out of the INTERSECT ALL. Again you can't say which of the set you will get, so the outer WHERE might let anywhere between 0 and min(M,N) rows out. With push down, M and N will be reduced by the WHERE before we do the intersection, so you still have 0 to min(M,N) rows out. The behavior will change, but it's still legal per spec AFAICT. EXCEPT, EXCEPT ALL: the same sort of analysis seems to hold. In short, it looks to me like the spec was carefully designed to allow push down. Pushing down a condition of this sort *does* change the behavior, but the new behavior is still within spec. The above analysis assumes that the WHERE condition is stable, ie its results for a row don't depend on the order in which the rows are tested or anything as weird as that. But we're assuming that already when we push down a qual in a non-set-operation case, I think. Comments? Are there any other considerations to worry about? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Rules and Views
On Thu, 1 Aug 2002, Tom Lane wrote: Stephan Szabo [EMAIL PROTECTED] writes: For union, queries that want to do something like use a temporary sequence to act sort of like rownum and do row limiting. Admittedly that's already pretty much unspecified behavior, but it does change the behavior in the place of duplicate removal. In addition, I think using bits of the spec we don't completely support you can have the same issue with the undefined behavior of which duplicate is returned for values that aren't the same but are equal, for example where the duplicate removal is in one collation but the outer comparison has a different explicitly given one. Hmm. I think this consideration boils down to whether the WHERE clause can give different results for rows that appear equal under the rules of UNION/EXCEPT/INTERSECT. If it gives the same result for any two such rows, then it's safe to push down; otherwise not. It's not too difficult to come up with examples. I invite you to play with select z,length(z) from (select 'abc'::char(7) as z intersect select 'abc'::char(8) as z) ss; and contemplate the effects of pushing down a qual involving length(z). Whether this particular case is very important in the real world is hard to say. But there might be more-important cases out there. And yet, I think we can do it anyway. The score card looks like this to me: UNION ALL: always safe to push down, since the rows will be passed independently to the outer WHERE anyway. UNION: it's unspecified which of a set of equal rows will be returned, and therefore the behavior would be unspecified anyway if the outer WHERE can distinguish the rows - you might get 1 row of the set out or none. If we push down, then we create a situation where the returned row will always be one that passes the outer WHERE, but that is a legal behavior. INTERSECT: again it's unspecified which of a set of equal rows will be returned, and so you might get 1 row out or none. If we push down then it's still unspecified whether you get a row out (example: if the outer WHERE will pass only for rows of the left table and not the right, then push down will result in no rows of the equal set being emitted, but that's a legal behavior). INTERSECT ALL: if a set of equal rows contains M rows from the left table and N from the right table, you're supposed to get min(M,N) rows of the set out of the INTERSECT ALL. Again you can't say which of the set you will get, so the outer WHERE might let anywhere between 0 and min(M,N) rows out. With push down, M and N will be reduced by the WHERE before we do the intersection, so you still have 0 to min(M,N) rows out. The behavior will change, but it's still legal per spec AFAICT. EXCEPT, EXCEPT ALL: the same sort of analysis seems to hold. Actually I think in except you may only push down to the left, since in this case you know that any duplicate from the right will not be returned (since there must be none). So, you can't potentially drop a row from the right side that may have been a duplicate of a left side row that does match the condition. If we assume two collations one case sensitive one not with the except in the non-sensitive and the where in the sensitive and a left with 'A' and right with 'a', it'd be incorrect to push a case sensitive where foo='A' down to the right since that'd change the output from zero rows to one. Something similar for except all since lowering the number of rows on the right can increase the number of returned rows above m-n (if say all m dups match the condition and none of n do) The above analysis assumes that the WHERE condition is stable, ie its results for a row don't depend on the order in which the rows are tested or anything as weird as that. But we're assuming that already when we push down a qual in a non-set-operation case, I think. In which case we don't have to worry about the nextval() case. ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Open 7.3 items
Jean-Michel POURE wrote: Le Mercredi 31 Juillet 2002 05:50, Bruce Momjian a ?crit : Here are the open items for 7.3. We have one more month to address them before beta. Is CREATE OR REPLACE VIEW on the list? No. It can still be done, but no one is working on it. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] CVS server problem!
Yes, it's compiling now...thanks. Greg On Thu, 2002-08-01 at 18:31, Marc G. Fournier wrote: Should be fixed now ... I found a rsync.core file, so it looks like the changes may have been more extensive then rsync could handle ... just ran it manually (or, rather, am running as I type this), so by the time you receive, a checkout should grab the right structures ... Let me know if it works now for you ... On 1 Aug 2002, Greg Copeland wrote: Seems the CVS server is not working correctly. I just deleted my CVS tree and did a fresh checkout of the pgsql module. Everything seemingly went well. After the check out completed, I did: [gcope@mouse pgsql]$ ./configure --with-tcl --with-java --with-python --with-perl checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking which template to use... linux checking whether to build with 64-bit integer date/time support... no checking whether to build with recode support... no checking whether NLS is wanted... no checking for default port number... 5432 checking for default soft limit on number of connections... 32 checking for gcc... gcc checking for C compiler default output... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes ./configure: ./src/template/linux: No such file or directory So, I did, ./configure which yields the same result. So, thinking maybe I just had a poorly timed checkout, I did an update. Doing so, looks like this: [gcope@mouse pgsql]$ cvs -z3 update -dP ? config.log cvs server: Updating . cvs server: Updating ChangeLogs cvs server: Updating MIGRATION cvs server: Updating config . . . src/backend/utils/mb/conversion_procs/utf8_and_iso8859_1 cvs server: Updating src/backend/utils/mb/conversion_procs/utf8_and_johab cvs server: Updating src/backend/utils/mb/conversion_procs/utf8_and_sjis cvs server: cannot open directory /projects/cvsroot/pgsql/src/backend/utils/mb/conversion_procs/utf8_and_sjis: No such file or directory cvs server: skipping directory src/backend/utils/mb/conversion_procs/utf8_and_sjis cvs server: Updating src/backend/utils/mb/conversion_procs/utf8_and_tcvn cvs server: cannot open directory /projects/cvsroot/pgsql/src/backend/utils/mb/conversion_procs/utf8_and_tcvn: No such file or directory cvs server: skipping directory src/backend/utils/mb/conversion_procs/utf8_and_tcvn cvs server: Updating src/backend/utils/mb/conversion_procs/utf8_and_uhc cvs server: cannot open directory /projects/cvsroot/pgsql/src/backend/utils/mb/conversion_procs/utf8_and_uhc: No such file or directory cvs server: skipping directory src/backend/utils/mb/conversion_procs/utf8_and_uhc cvs server: Updating src/backend/utils/misc cvs server: cannot open directory /projects/cvsroot/pgsql/src/backend/utils/misc: No such file or directory cvs server: skipping directory src/backend/utils/misc cvs server: Updating src/backend/utils/mmgr cvs server: cannot open directory /projects/cvsroot/pgsql/src/backend/utils/mmgr: No such file or directory cvs server: skipping directory src/backend/utils/mmgr cvs server: Updating src/backend/utils/sort cvs server: cannot open directory /projects/cvsroot/pgsql/src/backend/utils/sort: No such file or directory cvs server: skipping directory src/backend/utils/sort cvs server: Updating src/backend/utils/time cvs server: cannot open directory /projects/cvsroot/pgsql/src/backend/utils/time: No such file or directory cvs server: skipping directory src/backend/utils/time cvs server: Updating src/bin cvs server: cannot open directory /projects/cvsroot/pgsql/src/bin: No such file or directory cvs server: skipping directory src/bin So, I'm fairly sure something is awry. Greg On Mon, 2002-07-29 at 20:51, Tatsuo Ishii wrote: Can anyone fix this? $ cvs up can't create temporary directory /tmp/cvs-serv40296 No space left on device -- Tatsuo Ishii ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster signature.asc Description: This is a digitally signed message part
Re: [HACKERS] cvs checkout pgsql
Marc G. Fournier [EMAIL PROTECTED] writes: Well, it did work before, and I'd really like it to work again. I do not want to think about how Marc's broken apart the distribution when I'm looking at my local tree, and I don't want to think about it when I'm looking at cvsweb either. You don't have to think about anything ... god, does *nobody* read what they are replying to?? if you do a cvs checkout of pgsql, you will get exactly what you are used to ... Yes, I did a re-checkout, remerge of the rather large patch I'm working on, rebuild, etc. I've more or less recovered here, after wasting an hour or two that I had other uses for. But cvsweb is still broken: there is AFAICT no page that presents a unified view of the CVS tree anymore. If it's merely moved, how about telling me where? I quite concur with Peter's remarks: some discussion of this sort of change would have been appropriate in advance, rather than after. 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] Rules and Views
Stephan Szabo [EMAIL PROTECTED] writes: Actually I think in except you may only push down to the left, since in this case you know that any duplicate from the right will not be returned (since there must be none). So, you can't potentially drop a row from the right side that may have been a duplicate of a left side row that does match the condition. But we *want* to push down --- the point is to get some selectivity into the bottom queries. You're right that in a plain EXCEPT it would be possible to push only to the left, but that doesn't give the performance improvement we want. If we assume two collations one case sensitive one not with the except in the non-sensitive and the where in the sensitive and a left with 'A' and right with 'a', it'd be incorrect to push a case sensitive where foo='A' down to the right since that'd change the output from zero rows to one. You missed my point. Per spec, either zero or one rows out of the whole thing is okay, because either the 'A' or the 'a' row might be returned as the representative row for the group by the EXCEPT. Yes, the behavior may change, but it's still within spec. In which case we don't have to worry about the nextval() case. Yeah, I think nextval() and random() and so forth can be ignored; the transformations we already do will confuse the results for such cases, so one more isn't gonna make it worse. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Trimming the Fat: Getting code via CVSup ...
On Thu, Aug 01, 2002 at 12:56:11AM -0300, Marc G. Fournier wrote: I've just updated the README.cvsup file in order to reflect the changes, to provide a sample of how to download the whole thing, as well as instructions on how to do just a particular module: I'm using the following cvsup file, and the 'pgsql' module is empty (i.e. contains zero files): *default host=mcvsup.postgresql.org *default compress *default delete *default release=cvs *default delete use-rel-suffix *default base=/mnt/vol2/cvsup/pgsql *default prefix=/var/lib/cvs pgsql *default prefix=/var/lib/cvs/pgsql/src/interfaces libpqxx *default prefix=/var/lib/cvs/pgsql/contrib earthdistance Replacing 'pgsql' with 'pgsql-server' yields a 'no such module' warning message and the module is skipped. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] PGP Key ID: DB3C29FC ---(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] Open 7.3 items
On Wednesday 31 July 2002 04:56 pm, Bruce Momjian wrote: Thomas Lockhart wrote: Tom Lane wrote: I agree that if we could quickly come to a resolution about how this ought to work, there's plenty of time to go off and implement it. afaict someone else volunteered to do the work. There is no lack of consensus that this is a useful feature, at least among those who take responsibility to package PostgreSQL for particular platforms. How about letting them specify the requirements and if an acceptable solution emerges soon, we'll have it for 7.3... Added to open items: allow specification of configuration files in a different directory Thanks Bruce. I am going to review the previous thread and attempt to distill what can be done. I will then post a summary of what I found, with potential commentary. If a consensus is reached, I'd like to see the feature in 7.3. Peter had mentioned it as well; might want to see if he has done anything as yet with it. That being said, a patch exists for 7.2beta to effect a version of this change. I will also review this patch as I can and see what will be required to make this work in CURRENT. IMO, the key is that if the switch is not specified the current behavior is default. If specified, it will do its thing. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Rules and Views
On Thu, 2002-08-01 at 18:02, Tom Lane wrote:
Stephan Szabo [EMAIL PROTECTED] writes:
For union, queries that want to do something like use a temporary
sequence to act sort of like rownum and do row limiting. Admittedly
that's already pretty much unspecified behavior, but it does change
the behavior in the place of duplicate removal. In addition, I think
using bits of the spec we don't completely support you can have the
same issue with the undefined behavior of which duplicate is returned
for values that aren't the same but are equal, for example where the
duplicate removal is in one collation but the outer comparison has
a different explicitly given one.
Hmm. I think this consideration boils down to whether the WHERE clause
can give different results for rows that appear equal under the rules of
UNION/EXCEPT/INTERSECT.
Yes. I originally started to ponder this when trying to draw up a plan
for automatic generation of ON UPDATE DO INSTEAD rules for views. While
pushing down the WHERE clause is just a performance thing for SELECT it
is essential for ON UPDATE rules.
If it gives the same result for any two such
rows, then it's safe to push down; otherwise not.
It's not too difficult to come up with examples. I invite you to play
with
select z,length(z) from
(select 'abc'::char(7) as z intersect
select 'abc'::char(8) as z) ss;
and contemplate the effects of pushing down a qual involving length(z).
I guess the pushdown must also push implicit conversions done to parts
of union.
if that conversion were applied to z's in both parts of UNION then the
result should be the same.
select z,length(z) from
(
select 'abc'::char(7) as z
union
select 'abc '::char(8) as z
) ss where length(z) = 7;
becomes:
select z,length(z) from
(
select 'abc'::char(7) as z
where length(cast('abc'::char(7) as char(7))) = 7
union
select 'abc '::char(8) as z
where length(cast('abc '::char(8) as char(7))) = 7
) ss ;
which both return 'abc', 7
Of course it is beneficial to detect when the conversion is not needed,
so that indexes will be used if available.
---
Hannu
---(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] Trimming the Fat: Getting code via CVSup ...
Try now ... the download isn't going to work right though, as CVSup doesn't honor the modules file in CVSROOT which defines how 'pgsql' is *supposed* to work ... I'm going to work on this later tonight and see if I can find something in the docs that will allow it to work properly, but right now, other then gettin gat the sub-modules themselves, CVSup is broken ... anon-cvs will fair you better ... On Thu, 1 Aug 2002, Neil Conway wrote: On Thu, Aug 01, 2002 at 12:56:11AM -0300, Marc G. Fournier wrote: I've just updated the README.cvsup file in order to reflect the changes, to provide a sample of how to download the whole thing, as well as instructions on how to do just a particular module: I'm using the following cvsup file, and the 'pgsql' module is empty (i.e. contains zero files): *default host=mcvsup.postgresql.org *default compress *default delete *default release=cvs *default delete use-rel-suffix *default base=/mnt/vol2/cvsup/pgsql *default prefix=/var/lib/cvs pgsql *default prefix=/var/lib/cvs/pgsql/src/interfaces libpqxx *default prefix=/var/lib/cvs/pgsql/contrib earthdistance Replacing 'pgsql' with 'pgsql-server' yields a 'no such module' warning message and the module is skipped. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Rules and Views
On Thu, 1 Aug 2002, Tom Lane wrote: Stephan Szabo [EMAIL PROTECTED] writes: If we assume two collations one case sensitive one not with the except in the non-sensitive and the where in the sensitive and a left with 'A' and right with 'a', it'd be incorrect to push a case sensitive where foo='A' down to the right since that'd change the output from zero rows to one. You missed my point. Per spec, either zero or one rows out of the whole thing is okay, because either the 'A' or the 'a' row might be returned as the representative row for the group by the EXCEPT. Yes, the behavior may change, but it's still within spec. Except can't return 'A' or 'a', there is no representative row because n0. That's the difference with UNION and INTERSECT. If EXCEPT is specified, then Case: A) If m0 and n=0, then T contains exactly one duplicate of R. B) Otherwise, T contains no duplicate of R. So if T1 has a #dups0 and T2 has a #dups0 we should get no rows, but what if T1' (with the clause) has a #dups0 but T2' has a #dups=0? ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Open 7.3 items
Tom Lane wrote: Hannu Krosing [EMAIL PROTECTED] writes: This name mangling should be done at connect time and kept out of database, where each users name should always be fully resolved ([EMAIL PROTECTED]). I really like Hannu's approach to this. It seems to solve Marc's problem with a very simple, easily understood, easily implemented feature. All we need is a postmaster configuration parameter that (when TRUE) causes the postmaster to convert the passed username into 'username@databasename' before looking it up in pg_shadow. Yes, that is how the patch I submitted last night does it. (Actually, what I'd prefer it do is try first for username, and then username@databasename if plain username isn't found.) Yes, that would be very easy to do _except_ for pg_hba.conf which does a first-match for username. We could get into trouble there by trying two versions of the same name. Comments? With this approach, we have an underlying mechanism that supports installation-wide usernames, same as before, but with the flip of a switch you can configure the system to support per-database usernames. It's not fancy, maybe, but it will get the job done with an appropriate amount of effort. We've had several proposals in this thread for complicated extensions to the user naming mechanism. I think that's overdesigning the feature, because we have *no* examples of real-world need for such things except for Marc's situation. Let's keep it simple until we see real use cases that can drive the design of something fancy. Agreed. This may require raising the length of NAME type to be backwards compatible. Right, but we're planning to do that anyway. Yes, but that requires a protocol change, which we don't want to do for 7.3. My fix is to just extend the username on the server side and append the dbname if the switch is on. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Trimming the Fat, Part Deux ...
Lamar Owen wrote: And the sooner our very old perl client goes away, the better I like it. It is a good client, don't get me wrong: but DBD:Pg is the standard now. I have been in contact with Edmund about moving DBD into our CVS and updating CPAN ourselves. Should have a final answer soon. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Trim the Fat (Was: Re: Open 7.3 items )
Marc G. Fournier wrote: So, from the 'client side', y'all will still see everything as one big package, while from the 'server side', I'll have the seperate modules taht can be packaged independently ... Marc, how are you dealing with libpq's access to the server include files? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] getpid() function
Added to TODO: * Consistently name server-side internal functions --- Karel Zak wrote: On Thu, Aug 01, 2002 at 10:44:23AM -0400, Neil Conway wrote: On Thu, Aug 01, 2002 at 12:01:52PM +0200, Karel Zak wrote: Is there some common convention of names? No, there isn't (for example, pg_stat_backend_id() versus I know -- for this I asked. IMHO for large project like PostgreSQL it's important. It's not good if there is possible speculate about name of new function. It must be unmistakable -- for this is needful make some convension. If somebody add new function and it's released, it's in the PostgreSQL almost forever. current_schema() -- or pg_get_viewdef() versus obj_description() ). Now that we have table functions, we might be using more built-in functions to provide information to the user -- so there will be an increasing need for some kind of naming convention for built-in functions. However, establishing a naming convention without breaking backwards compatibility might be tricky. Yes, but we can try be clean for new stuff. Karel -- Karel Zak [EMAIL PROTECTED] http://home.zf.jcu.cz/~zakkr/ C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] getpid() function
I can rename backend_pid if people want. I just made it consistent with the other functions in that docs area. Comments? --- Karel Zak wrote: On Thu, Aug 01, 2002 at 10:44:23AM -0400, Neil Conway wrote: On Thu, Aug 01, 2002 at 12:01:52PM +0200, Karel Zak wrote: Is there some common convention of names? No, there isn't (for example, pg_stat_backend_id() versus I know -- for this I asked. IMHO for large project like PostgreSQL it's important. It's not good if there is possible speculate about name of new function. It must be unmistakable -- for this is needful make some convension. If somebody add new function and it's released, it's in the PostgreSQL almost forever. current_schema() -- or pg_get_viewdef() versus obj_description() ). Now that we have table functions, we might be using more built-in functions to provide information to the user -- so there will be an increasing need for some kind of naming convention for built-in functions. However, establishing a naming convention without breaking backwards compatibility might be tricky. Yes, but we can try be clean for new stuff. Karel -- Karel Zak [EMAIL PROTECTED] http://home.zf.jcu.cz/~zakkr/ C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Open 7.3 items
On Thu, 2002-08-01 at 16:17, Tom Lane wrote: Hannu Krosing [EMAIL PROTECTED] writes: This name mangling should be done at connect time and kept out of database, where each users name should always be fully resolved ([EMAIL PROTECTED]). I really like Hannu's approach to this. It seems to solve Marc's problem with a very simple, easily understood, easily implemented feature. All we need is a postmaster configuration parameter that (when TRUE) causes the postmaster to convert the passed username into 'username@databasename' before looking it up in pg_shadow. (Actually, what I'd prefer it do is try first for username, and then username@databasename if plain username isn't found.) This should not really be @databasename, but rather a @domainname as Mark does in fact want to use the same user from some virtual host (==domain) for more than one database sometimes. Using databasename as a domainname is just the quickest way to resolve the domainname if no more info about it is given. Thinking of the @xxx part as a domainname and not tying it to databasename would be beneficial in case we later want to use other kinds of domains (like NT, DNS/mail, YP or Kerberos domains for example) If need arises we could later split out the @xxx part to usedomain field and perhaps also add usedomainkind field in order to manage that info in databse instead of pg_hba.conf. - Hannu ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] cvs checkout pgsql
Marc G. Fournier wrote: ... is once more 'normal' ... there are three modules right now setup: earthdistance libpqxx pgsql-server pgsql combines all three of the above to transparently give the equivalent of the whole distribution from its component parts ... Marc, I have to ask, why did you split them up that way. I thought /contrib, /interfaces, /doc would be the way to go. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(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] getpid() function
On Thu, 2002-08-01 at 19:41, Bruce Momjian wrote: Added to TODO: * Consistently name server-side internal functions I'd suggest: * Make up rules for consistently naming server-side internal functions * Consistently name _new_ server-side internal functions * make a plan for moving existing server-side internal functions to consistent naming --- Hannu ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Trim the Fat (Was: Re: Open 7.3 items )
On Thu, 1 Aug 2002, Bruce Momjian wrote: Marc G. Fournier wrote: So, from the 'client side', y'all will still see everything as one big package, while from the 'server side', I'll have the seperate modules taht can be packaged independently ... Marc, how are you dealing with libpq's access to the server include files? I haven't touched libpq yet ... I'm talking with the libpqxx guys right now concerning getting the standalone libpqxx to work, and will be working on figuring out how to get the 'master configure' to make use of the standalone configure once that is fixed ... I want to get one module to work cleanly before looking at any others ... ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Trim the Fat (Was: Re: Open 7.3 items )
Marc G. Fournier wrote: On Thu, 1 Aug 2002, Bruce Momjian wrote: Marc G. Fournier wrote: So, from the 'client side', y'all will still see everything as one big package, while from the 'server side', I'll have the seperate modules taht can be packaged independently ... Marc, how are you dealing with libpq's access to the server include files? I haven't touched libpq yet ... I'm talking with the libpqxx guys right now concerning getting the standalone libpqxx to work, and will be working on figuring out how to get the 'master configure' to make use of the standalone configure once that is fixed ... I want to get one module to work cleanly before looking at any others ... But isn't libpq++ just going to be part of interfaces? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Trimming the Fat, Part Deux ...
Bruce Momjian wrote: Lamar Owen wrote: And the sooner our very old perl client goes away, the better I like it. It is a good client, don't get me wrong: but DBD:Pg is the standard now. I have been in contact with Edmund about moving DBD into our CVS and updating CPAN ourselves. Should have a final answer soon. OK, I got the go-ahead from Edmund. We will have DBD:pg in the 7.3 tarball. I will add it to CVS today or tomorrow. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?
On Tue, 2002-07-30 at 14:54, Hannu Krosing wrote: On Tue, 2002-07-30 at 16:00, Curt Sampson wrote: On 30 Jul 2002, Hannu Krosing wrote: On Tue, 2002-07-30 at 14:51, Adrian 'Dagurashibanipal' von Bidder wrote: Bruce Momjian: It causes too much complexity in other parts of the system. That's one reason. Seems like somewhat valid reason. But still not enough to do a lot of work _and_ annoy a lot of existing users :) It's almost unquestionably more work to maintain than to drop. Dropping support for it is a one-time operation. Maintaining it is an ongoing expense. I would not rush to drop advanced features, as they may be hard to put back later. If they stay in, even in broken form, then there wont be nearly as much patches which make fixing them harder. I seem to find this argument a lot on the list here. For some reason, many of the developers are under the impression that even if code is never touched, it has a very high level of effort to keep it in the code base. That is, of course, completely untrue. Now then, I'm not saying that something as central as the topic at hand has a zero maintenance cost associated with it, especially if it's constantly being run into by the developers, but I do see it used WAY to often here for it to be applicable in every case. From what I can tell, in many cases, when one developer on the list doesn't want to maintain or sees little value in a feature, it suddenly seems to have a high price associated with it. We need to be sure we're making the distinction between, I don't care to maintain this, and, maintaining this code is prohibitively high given it's feature return...because In other words, I find this argument used often here will little to nothing used in context which would quantify it. Worse yet, it generally goes unchallenged and unquestioned. I'm afraid that we have already dropped too much. For example we dropped time travel, but recent versions of Oracle now have some form of it, usable mostly for recovering accidentally deleted (and committed rows), although it is much harder to implement it using logs than using MVCC. I must admit, I never understood this myself but I'm sure I'm ignorant of the details. That's a straw man argument. Actually it was meant to be 'one straw man against another straw man argument' ;) Was clear to me! I thought you made the point rather well. What we (or I, anyway) are arguing is that the relational model does everything that table inheritance does, and at least as easily. The problem is that 'the relational model' does nothing by itself. It is always the developers/DBAs who have to do things. And at least for some brain shapes it is much more convenient to inherit tables than to (re)factor stuff into several tables to simulate inheritance using the relational model. Agreed. It's important to remember, there are some cases where the conceptual implications can allow for more freedom in implementation. This is the point that was being made with the pure C comment. Sure, I can do pretty much anything in asm, but that approach doesn't suddenly invalidate every other way/language/concept/idiom to trying to accomplish as given task. Simply put, much of the power you get from any tool is often the flexibility of a given tool to address a problem domain in many different ways rather than just one. Just because it doesn't fit your paradigm doesn't mean it doesn't fit nicely into someone else's. I still think that inheritance should be enchanced and made compatible with standards not removed. I completely agree with that! Extending the model adds complexity without adding the ability to do things you couldn't easily do before. (This, IMHO, makes table inheritance quite inelegant.) Then explain why SQL99 has included inheritance ? Yes please. I'm very interested in hearing a rebuttal to this one. Greg signature.asc Description: This is a digitally signed message part
Re: [HACKERS] Open 7.3 items
I have discussed the idea of contributing our Win32 work to the PostgreSQL project with management. We have also converted all of the utilities (initdb, psql, pg_dump, pg_restore, pg_id, pg_passwd, etc.) Management is (rightfully) concerned about recouping the many thousands of dollars invested in the Win32 conversion. I pointed out that future versions would contain our enhancements and therefore benefit us directly. I pointed out that maintenance is 80% of the cost of a software system and a world-wide team of good programmers would be maintaining the code for all to benefit. And last but not least, good computer Kharma. ;-) They will have to cogitate over it a bit, I think. If they agree, I will make a file with our source tree available on an ftp site. -Original Message- From: Bruce Momjian [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 31, 2002 1:48 PM To: Dann Corbit Cc: Tom Lane; PostgreSQL-development Subject: Re: [HACKERS] Open 7.3 items If you can contribute it, I think it would be valuable to the two other Win32 projects that are working on porting the 7.3 code to Win32. I don't think they will have any code ready for 7.3 but they may have a few pieces they want to get in to make their 7.3 patching job easier, like renaming macros or variables or something. -- - Dann Corbit wrote: -Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 30, 2002 9:50 PM To: Bruce Momjian Cc: PostgreSQL-development Subject: Re: [HACKERS] Open 7.3 items [snip] Win32 - timefame? I may be able to contribute the Win32 stuff we have done here. (Not sure of it, but they do seem more open to the idea now). It's only for 7.1.3, and so I am not sure how helpful it would be. There is also a bunch of stuff that looks like this in the code: #ifdef ICKY_WIN32_KLUDGE /* Bletcherous hack to make it work in Win32 goes here... */ #else /* Normal code goes here... */ #endif Let me know if you are interested. ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] cvs checkout pgsql
Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] writes: ... is once more 'normal' ... Uh, it's completely broken as far as I can tell. $ pwd /home/postgres/pgsql/src/bin/pg_dump $ cvs status cvs server: Examining . cvs server: failed to create lock directory for `/cvsroot/pgsql/src/bin/pg_dump' (/cvsroot/pgsql/src/bin/pg_dump/#cvs.lock): No such file or directory cvs server: failed to obtain dir lock in repository `/cvsroot/pgsql/src/bin/pg_dump' cvs [server aborted]: read lock failed - giving up $ Also, http://developer.postgresql.org/cvsweb.cgi/pgsql/ isn't working. This makes it a little difficult to get any work done :-( Yes, I just deleted my CVS tree and re-checked out. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] Disable foreign key constraints
Do we have any way to disable foreign key constraints? If not, I would like to add it to TODO. I was asked for this feature several times at O'Reilly. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Trimming the Fat, Part Deux ...
On Thu, 1 Aug 2002, Bruce Momjian wrote: Bruce Momjian wrote: Lamar Owen wrote: And the sooner our very old perl client goes away, the better I like it. It is a good client, don't get me wrong: but DBD:Pg is the standard now. I have been in contact with Edmund about moving DBD into our CVS and updating CPAN ourselves. Should have a final answer soon. OK, I got the go-ahead from Edmund. We will have DBD:pg in the 7.3 tarball. I will add it to CVS today or tomorrow. Hmm, according README from DBD-Pg ( 1.13 ), it's maintained now by Jeffrey W. Baker ([EMAIL PROTECTED]) DBD::Pg -- a PostgreSQL interface for Perl 5. $Id: README,v 1.3 2002/04/10 02:01:38 jwb Exp $ Copyright (c) 1997,1998,1999,2000 Edmund Mergl Copyright (c) 2002 Jeffrey W. Baker Portions Copyright (c) 1994,1995,1996,1997 Tim Bunce I'm a little bit aware about DBD::Pg because it needs many changes and testing to be 7.3 compliant. Jeffrey, wake up :-) Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Trimming the Fat, Part Deux ...
Oleg Bartunov wrote: On Thu, 1 Aug 2002, Bruce Momjian wrote: Bruce Momjian wrote: Lamar Owen wrote: And the sooner our very old perl client goes away, the better I like it. It is a good client, don't get me wrong: but DBD:Pg is the standard now. I have been in contact with Edmund about moving DBD into our CVS and updating CPAN ourselves. Should have a final answer soon. OK, I got the go-ahead from Edmund. We will have DBD:pg in the 7.3 tarball. I will add it to CVS today or tomorrow. Hmm, according README from DBD-Pg ( 1.13 ), it's maintained now by Jeffrey W. Baker ([EMAIL PROTECTED]) DBD::Pg -- a PostgreSQL interface for Perl 5. $Id: README,v 1.3 2002/04/10 02:01:38 jwb Exp $ Copyright (c) 1997,1998,1999,2000 Edmund Mergl Copyright (c) 2002 Jeffrey W. Baker Portions Copyright (c) 1994,1995,1996,1997 Tim Bunce I'm a little bit aware about DBD::Pg because it needs many changes and testing to be 7.3 compliant. Jeffrey, wake up :-) Oh, that's strange. I wonder why Edmund didn't mention that. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Open 7.3 items
On Thu, 1 Aug 2002, Dann Corbit wrote: I have discussed the idea of contributing our Win32 work to the PostgreSQL project with management. We have also converted all of the utilities (initdb, psql, pg_dump, pg_restore, pg_id, pg_passwd, etc.) Management is (rightfully) concerned about recouping the many thousands of dollars invested in the Win32 conversion. Ask them if they are willing to pay us for the many thousands of dollars we've all invested in giving them something to even convert? *grin* ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Rules and Views
Stephan Szabo [EMAIL PROTECTED] writes: So if T1 has a #dups0 and T2 has a #dups0 we should get no rows, but what if T1' (with the clause) has a #dups0 but T2' has a #dups=0? Um, you're right --- pushing down into the right-hand side would reduce N, thereby possibly *increasing* the number of output rows not reducing it. My mistake ... should have worked out the EXCEPT case in more detail. This says that we can't push down at all in the EXCEPT ALL case, I think, and I'm leery about whether we should push for EXCEPT. But the UNION and INTERSECT cases are probably the important ones anyway. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Trim the Fat (Was: Re: Open 7.3 items )
On Thu, 1 Aug 2002, Bruce Momjian wrote: Marc G. Fournier wrote: On Thu, 1 Aug 2002, Bruce Momjian wrote: Marc G. Fournier wrote: So, from the 'client side', y'all will still see everything as one big package, while from the 'server side', I'll have the seperate modules taht can be packaged independently ... Marc, how are you dealing with libpq's access to the server include files? I haven't touched libpq yet ... I'm talking with the libpqxx guys right now concerning getting the standalone libpqxx to work, and will be working on figuring out how to get the 'master configure' to make use of the standalone configure once that is fixed ... I want to get one module to work cleanly before looking at any others ... But isn't libpq++ just going to be part of interfaces? Huh? Each module is to be designed as a standalone project/distribution ... in order to appease those that don't feel that the change is worth it, I'm making, essentially, a 'meta-module' that will pull in the seperate modules into what you've all gotten used to from a development standpoint ... If you checkout pgsql, you will see what you are used to seeing, locally stored in pgsql If you checkout libpqxx, you will just get libpqxx, locally stored in libpqxx If you checkout interfaces, you will get all of the interfaces listed in a 'meta module' consisting of the various interfaces, locally stored in a directory of pgsql/src/interfaces/* For those that are used to cheking out pgsql, continue to do so ... for ppl like Jergeon(sp?), he will checkout libpqxx itself and work on it as if it were a standalone project, but when we package up pgsql, it will get pulled in along with everything else, so that for those that have nothing better to do then download everyhting and the kitchen sink, they can ... At the same time as the distribution is made, a libpqxx.tar.gz will be created, that will be a self-contained source tree for just that, so that those doing ports on the *BSDs or rpms/etc on Linux have pretty much pre-made distros that they don't have to slice and dice (ie. for FreeBSD, you'd do something like go into /usr/ports/database/pgsql-libpqxx, type 'make' and it would automatically go out, download libpq.tar.gz, install it as a dependency and then grab and install the libpqxx file ... if you had already installed libpq previously, for mod_php4, for example, then it would just download and install the libpqxx tar file) ... Unless I break something along the way, as far as you are concerned, nothing has changed ... just keep checking out pgsql as you always have ... but for those of us that pay for our bandwidth by the byte, we'll now be able to download *only* what we require, saving us both time and money ... ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] getpid() function
On Thu, Aug 01, 2002 at 05:09:52PM +0200, Karel Zak wrote: I know -- for this I asked. IMHO for large project like PostgreSQL it's important. It's not good if there is possible speculate about name of new function. It must be unmistakable -- for this is needful make some convension. If somebody add new function and it's released, it's in the PostgreSQL almost forever. I agree that a naming convention would be useful in some circumstances, but for commonly-used functions, I think it would do more harm than good. 'pg_nextval()' is awfully ugly, for example. And if we're going to have a naming convention for builtin functions, what about builtin types? 'pg_int4', anyone? :-) Cheers, Neil -- Neil Conway [EMAIL PROTECTED] PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Trimming the Fat, Part Deux ...
On Thu, 1 Aug 2002, Bruce Momjian wrote: Bruce Momjian wrote: Lamar Owen wrote: And the sooner our very old perl client goes away, the better I like it. It is a good client, don't get me wrong: but DBD:Pg is the standard now. I have been in contact with Edmund about moving DBD into our CVS and updating CPAN ourselves. Should have a final answer soon. OK, I got the go-ahead from Edmund. We will have DBD:pg in the 7.3 tarball. I will add it to CVS today or tomorrow. If you know how to, please import it as a seperate module, do not add it to the pgsql tree itself ... if you don't know how, please just forward it onto me and I'll get it into the repository ... ---(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] Trimming the Fat, Part Deux ...
Ummm ... stupid question, but can we even bring this into the 'core'? You may distribute under the terms of either the GNU General Public License or the Artistic License, as specified in the Perl README file. On Thu, 1 Aug 2002, Oleg Bartunov wrote: On Thu, 1 Aug 2002, Bruce Momjian wrote: Bruce Momjian wrote: Lamar Owen wrote: And the sooner our very old perl client goes away, the better I like it. It is a good client, don't get me wrong: but DBD:Pg is the standard now. I have been in contact with Edmund about moving DBD into our CVS and updating CPAN ourselves. Should have a final answer soon. OK, I got the go-ahead from Edmund. We will have DBD:pg in the 7.3 tarball. I will add it to CVS today or tomorrow. Hmm, according README from DBD-Pg ( 1.13 ), it's maintained now by Jeffrey W. Baker ([EMAIL PROTECTED]) DBD::Pg -- a PostgreSQL interface for Perl 5. $Id: README,v 1.3 2002/04/10 02:01:38 jwb Exp $ Copyright (c) 1997,1998,1999,2000 Edmund Mergl Copyright (c) 2002 Jeffrey W. Baker Portions Copyright (c) 1994,1995,1996,1997 Tim Bunce I'm a little bit aware about DBD::Pg because it needs many changes and testing to be 7.3 compliant. Jeffrey, wake up :-) Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Trimming the Fat, Part Deux ...
Marc G. Fournier wrote: Ummm ... stupid question, but can we even bring this into the 'core'? You may distribute under the terms of either the GNU General Public License or the Artistic License, as specified in the Perl README file. Artistic License is fine, I think. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(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] Disable foreign key constraints
Bruce Momjian [EMAIL PROTECTED] writes: Do we have any way to disable foreign key constraints? You can drop and re-add the constraint relatively painlessly in 7.3. Formerly it took hacking on pg_trigger. 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] Disable foreign key constraints
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Do we have any way to disable foreign key constraints? You can drop and re-add the constraint relatively painlessly in 7.3. Formerly it took hacking on pg_trigger. OK, let's see if it comes up after 7.3. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Trimming the Fat, Part Deux ...
On Thursday 01 August 2002 02:21 pm, Bruce Momjian wrote: Bruce Momjian wrote: Lamar Owen wrote: And the sooner our very old perl client goes away, the better I like it. It is a good client, don't get me wrong: but DBD:Pg is the standard now. I have been in contact with Edmund about moving DBD into our CVS and updating CPAN ourselves. Should have a final answer soon. OK, I got the go-ahead from Edmund. We will have DBD:pg in the 7.3 tarball. I will add it to CVS today or tomorrow. Um, is putting it into our tarball necessary, or even desireable? It is separately maintained as part of CPAN. Is there some fundamental reason that we _must_ ship a perl client (the same goes for tcl/tk/python/c++ as well) if it is adequately maintained in the standard location? Perlers know to go to CPAN. Likewise Pythonistas have their own place. And that's the crux of Marc's message, I believe -- why can't we minimize here? -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Rules and Views
On Thu, 1 Aug 2002, Tom Lane wrote: Stephan Szabo [EMAIL PROTECTED] writes: So if T1 has a #dups0 and T2 has a #dups0 we should get no rows, but what if T1' (with the clause) has a #dups0 but T2' has a #dups=0? Um, you're right --- pushing down into the right-hand side would reduce N, thereby possibly *increasing* the number of output rows not reducing it. My mistake ... should have worked out the EXCEPT case in more detail. This says that we can't push down at all in the EXCEPT ALL case, I think, and I'm leery about whether we should push for EXCEPT. But the UNION and INTERSECT cases are probably the important ones anyway. I think that we can push to the left in both (should is a separate issue). If the condition is true for all of the left hand dups, we can choose to have emitted such rows as the output of the EXCEPT ALL in the theoretical case so that the output is the same, max(0, m-n) rows. If the condition is false for any of the left hand dups, we can safely return any number of rows between 0 and max(0,m-n) rows since we can say that the difference were rows that failed the where clause. If we push the condition down, we'll get some number m1 rows that succeed the condition (with m1m), so returning max(0, m1-n) should be safe. If the condition is false for all of the rows, m1=0 so we'll correctly return no rows. I think. ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] getpid() function
Neil Conway writes: On Thu, Aug 01, 2002 at 12:01:52PM +0200, Karel Zak wrote: Is there some common convention of names? No, there isn't (for example, pg_stat_backend_id() versus current_schema() -- or pg_get_viewdef() versus obj_description() ). The pg_ naming scheme is obsolete because system and user namespaces are now isolated. Anything involving get is also redundant, IMHO, because we aren't dealing with object-oriented things. Besides that, the convention in SQL seems to be to use full noun phrases with words separated by underscores. So if pg_get_viewdef where reinvented today, by me, it would be called view_definition. A whole 'nother issue is to use the right terms for the right things. For example, the term backend is rather ambiguous and PostgreSQL uses it differently from everyone else. Instead I would use server process when referring to the PID. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Open 7.3 items
Bruce Momjian [EMAIL PROTECTED] writes: (Actually, what I'd prefer it do is try first for username, and then username@databasename if plain username isn't found.) Yes, that would be very easy to do _except_ for pg_hba.conf which does a first-match for username. We could get into trouble there by trying two versions of the same name. Comments? Hm. I think we'd have to switch around the order of stuff so that we look at the flat-file copy of pg_shadow first. Then we'd know which flavor of name we have, and we can proceed with the pg_hba match. The reason it's worth doing this is that 'postgres', for example, should be an installation-wide username even when you're using db-local names for ordinary users. This may require raising the length of NAME type to be backwards compatible. Right, but we're planning to do that anyway. Yes, but that requires a protocol change, which we don't want to do for 7.3. What? We've been discussing raising NAMEDATALEN for months, and no one's claimed that it qualifies as a protocol version change. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Module Portability
Contrib modules does have such possibility. For example: CREATE FUNCTION ltree_in(opaque) RETURNS opaque AS 'MODULE_PATHNAME' LANGUAGE 'c' with (isstrict); Oleg On Thu, 1 Aug 2002, Paul Ramsey wrote: All this talk of modularity reminds me of a pet peeve: doing dump/restore upgrades when your databases include extension functions is highly clunky, because extension functions include the fully qualified path to the linking library. So, for example create function geometry_in(opaque) RETURNS GEOMETRY AS '/opt/pgsql72/lib/contrib/libpostgis.so.0.7' LANGUAGE 'c' with (isstrict); If I do a pg_dumpall on an old database and try to pipe into a new database, things can get messy pretty fast. It would be nice if pgsql had a 'default library location' which it tried to load linking libraries from, in much the same way apache uses libexec. Then my definition could just be: create function geometry_in(opaque) RETURNS GEOMETRY AS 'libpostgis.so.0.7' LANGUAGE 'c' with (isstrict); Which would be alot more portable across installations. I mean, right now I can render my database inoperative just by moving my executable installation tree to a new path. Nice. Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Open 7.3 items
Bruce Momjian writes: OK, I have attached a patch for testing. Sample output is: $ sql -U guest test psql: FATAL: user test.guest does not exist $ createuser test.guest I will object to any scheme that makes any characters in the user name magic. Two reasons: First, do it right, make a separate column. Second, several tools use URI syntax to specify data sources. This will break any feature that relies on being able to put special characters into the user name. The right solution to having database-local user names is putting extra information into pg_shadow regarding which database this user applies to. It could be an array or some separate authentication domain thing. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Trim the Fat (Was: Re: Open 7.3 items )
Marc G. Fournier writes: Next, unless Peter knows how to do it already, I've gotta learn to make configure more intelligent, so that for all intents, the pieces look like one package when building, not just when coding ... It is possible, but it's not going to work. There is a lot of interdependent and shared C code that needs to be put somewhere. The build infrastructure is not ready to handle missing sub- or superdirectories at all. Where is all the documentation going to go? How are the installation instructions going to cope with the fact that no one knows where everything is? This whole things is a worthwhile idea, to some extent, but a lot more planning needs to be done. In the meantime I humbly suggest you look for a better package manager rather than letting it all out on us. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Open 7.3 items
Tom Lane writes: We've had several proposals in this thread for complicated extensions to the user naming mechanism. I think that's overdesigning the feature, because we have *no* examples of real-world need for such things except for Marc's situation. Let's keep it simple until we see real use cases that can drive the design of something fancy. I don't buy this argument. The reason we have no examples is that people are happily using the feature and don't have any reason to tell the world about it. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Open 7.3 items
Lamar Owen writes: allow specification of configuration files in a different directory I am going to review the previous thread and attempt to distill what can be done. I will then post a summary of what I found, with potential commentary. If a consensus is reached, I'd like to see the feature in 7.3. The end result of the discussion was that no one could come up with a bright idea to secure the configuration files without doing anything bogus during installation. Another issue, which becomes even more problematic if you factor in the WAL file location discussion, is that if we drive the location of the data from the configuration file instead of vice versa, we need to have initdb smart enough to read those files. Finally, I recall that a major reason to have these files in a separate place is to be able to share them. But that won't work because those files contain port numbers, data directory locations, etc. which can't be shared. That needs a better plan than possibly use command-line options to override. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Module Portability
Correct me if I am wrong (I often am) but isn't MODULE_PATHNAME replaced by the fully qualified module path during the build process? I mean, the source code is movable, but a running installed system, with real data, is not movable, because MODULE_PATHNAME gets mapped to /usr/local/mypgsql/lib/blah.so or somesuch. Oleg Bartunov wrote: Contrib modules does have such possibility. For example: CREATE FUNCTION ltree_in(opaque) RETURNS opaque AS 'MODULE_PATHNAME' LANGUAGE 'c' with (isstrict); Oleg On Thu, 1 Aug 2002, Paul Ramsey wrote: All this talk of modularity reminds me of a pet peeve: doing dump/restore upgrades when your databases include extension functions is highly clunky, because extension functions include the fully qualified path to the linking library. So, for example create function geometry_in(opaque) RETURNS GEOMETRY AS '/opt/pgsql72/lib/contrib/libpostgis.so.0.7' LANGUAGE 'c' with (isstrict); If I do a pg_dumpall on an old database and try to pipe into a new database, things can get messy pretty fast. It would be nice if pgsql had a 'default library location' which it tried to load linking libraries from, in much the same way apache uses libexec. Then my definition could just be: create function geometry_in(opaque) RETURNS GEOMETRY AS 'libpostgis.so.0.7' LANGUAGE 'c' with (isstrict); Which would be alot more portable across installations. I mean, right now I can render my database inoperative just by moving my executable installation tree to a new path. Nice. Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 -- __ / | Paul Ramsey | Refractions Research | Email: [EMAIL PROTECTED] | Phone: (250) 885-0632 \_ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Trim the Fat (Was: Re: Open 7.3 items )
Marc G. Fournier writes: I haven't touched libpq yet ... I'm talking with the libpqxx guys right now concerning getting the standalone libpqxx to work, and will be working on figuring out how to get the 'master configure' to make use of the standalone configure once that is fixed ... I want to get one module to work cleanly before looking at any others ... I fail to understand how this mess is going to achieve anything. If you like, you can assemble or split the modules into trees or tarballs after you have them checked out, or even after you have downloaded and unpacked them. But a source code repository is not a package manager. Moreover, I would really like it if there was *some* discussion before we are presented with done deals. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Module Portability
Paul Ramsey writes: It would be nice if pgsql had a 'default library location' Sure. That's why it was implemented in 7.2. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Trimming the Fat, Part Deux ...
Bruce Momjian writes: Artistic License is fine, I think. The Artistic License doesn't even qualify as Free Software as far as the FSF is concerned. More generally, it is a different license, and that is a problem. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Trimming the Fat, Part Deux ...
Bruce Momjian writes: OK, I got the go-ahead from Edmund. We will have DBD:pg in the 7.3 tarball. I will add it to CVS today or tomorrow. Please, no more Perl modules in our CVS! The ones we have are already messy enough to build. I thought we were talking about trimming the source tree, not adding more. Why not put it on gborg or somewhere else? -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Trimming the Fat, Part Deux ...
On Thursday 01 August 2002 04:37 pm, Peter Eisentraut wrote: I thought we were talking about trimming the source tree, not adding more. Why not put it on gborg or somewhere else? It's already in CPAN. A link to CPAN should suffice, IMHO. I also thought we were discussing trimming the tree; and that was a good feeling. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Open 7.3 items
On Thursday 01 August 2002 04:06 pm, Peter Eisentraut wrote: Another issue, which becomes even more problematic if you factor in the WAL file location discussion, is that if we drive the location of the data from the configuration file instead of vice versa, we need to have initdb smart enough to read those files. Hmm, I hadn't thought about that -- but I like that idea. Not exclusive of the existing way, either. But alongside it. More thought required. Finally, I recall that a major reason to have these files in a separate place is to be able to share them. But that won't work because those files contain port numbers, data directory locations, etc. which can't be shared. That needs a better plan than possibly use command-line options to override. No, the major reason was to allow the config files to live in a different area than the data files without symlink kludges. The reasons why an admin might want this are manifold. The reason I want it is to simplify multiple postmasters in an RPM installation. You can then blow away the whole PGDATA tree and start from scratch without losing your config files. You had an idea along these lines, and I was quite OK with the majority of it. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Module Portability
Color me embarrased. / Peter Eisentraut wrote: Paul Ramsey writes: It would be nice if pgsql had a 'default library location' Sure. That's why it was implemented in 7.2. -- Peter Eisentraut [EMAIL PROTECTED] -- __ / | Paul Ramsey | Refractions Research | Email: [EMAIL PROTECTED] | Phone: (250) 885-0632 \_ ---(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] getpid() function
Peter Eisentraut wrote: Neil Conway writes: On Thu, Aug 01, 2002 at 12:01:52PM +0200, Karel Zak wrote: Is there some common convention of names? No, there isn't (for example, pg_stat_backend_id() versus current_schema() -- or pg_get_viewdef() versus obj_description() ). The pg_ naming scheme is obsolete because system and user namespaces are now isolated. Anything involving get is also redundant, IMHO, because we aren't dealing with object-oriented things. Besides that, the convention in SQL seems to be to use full noun phrases with words separated by underscores. So if pg_get_viewdef where reinvented today, by me, it would be called view_definition. A whole 'nother issue is to use the right terms for the right things. For example, the term backend is rather ambiguous and PostgreSQL uses it differently from everyone else. Instead I would use server process when referring to the PID. Yes, I wanted to match libpq's function, which is the way people used to get the pid. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Open 7.3 items
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: (Actually, what I'd prefer it do is try first for username, and then username@databasename if plain username isn't found.) Yes, that would be very easy to do _except_ for pg_hba.conf which does a first-match for username. We could get into trouble there by trying two versions of the same name. Comments? Hm. I think we'd have to switch around the order of stuff so that we look at the flat-file copy of pg_shadow first. Then we'd know which flavor of name we have, and we can proceed with the pg_hba match. The reason it's worth doing this is that 'postgres', for example, should be an installation-wide username even when you're using db-local names for ordinary users. Yes, that's why my code had a special case for 'postgres' or whatever super-user name it was installed with. I think it is cleaner to just read the install username. Also, right now, pg_pwd only contains usernames that have passwords, not all of them. This may require raising the length of NAME type to be backwards compatible. Right, but we're planning to do that anyway. Yes, but that requires a protocol change, which we don't want to do for 7.3. What? We've been discussing raising NAMEDATALEN for months, and no one's claimed that it qualifies as a protocol version change. I thought they were talking about increasing the length of the user NAME that comes of the wire. That is currently 32. I see now he was just talking about NAMEDATALEN. Good thing we are prepending the database name after receiving the name. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Open 7.3 items
Peter Eisentraut wrote: Tom Lane writes: We've had several proposals in this thread for complicated extensions to the user naming mechanism. I think that's overdesigning the feature, because we have *no* examples of real-world need for such things except for Marc's situation. Let's keep it simple until we see real use cases that can drive the design of something fancy. I don't buy this argument. The reason we have no examples is that people are happily using the feature and don't have any reason to tell the world about it. Well, we are going to find out in 7.3 when the secondary password file is no longer supported. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Open 7.3 items
On Thu, 1 Aug 2002, Bruce Momjian wrote: Peter Eisentraut wrote: Bruce Momjian writes: OK, I have attached a patch for testing. Sample output is: $ sql -U guest test psql: FATAL: user test.guest does not exist $ createuser test.guest I will object to any scheme that makes any characters in the user name magic. Two reasons: First, do it right, make a separate column. Second, several tools use URI syntax to specify data sources. This will break any feature that relies on being able to put special characters into the user name. The right solution to having database-local user names is putting extra information into pg_shadow regarding which database this user applies to. It could be an array or some separate authentication domain thing. OK, if you object, you can say goodbye to this feature for 7.3. I can supply the patch to Marc and anyone else who wants it but I am not inclined nor convinced we need that level of work for this feature. So we end up with nothing. Stupid qustion .. but why can't you just add a 'domain' column to pg_passwd/pg_shadow so that its stored as two fields instead of one? Which I believe is what Pter is/was suggesting ... ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] PITR, checkpoint, and local relations
J.R needs comments on this. PITR has problems because local relations aren't logged to WAL. Suggestions? --- J. R. Nield wrote: As per earlier discussion, I'm working on the hot backup issues as part of the PITR support. While I was looking at the buffer manager and the relcache/MyDb issues to figure out the best way to work this, it occurred to me that PITR will introduce a big problem with the way we handle local relations. The basic problem is that local relations (rd_myxactonly == true) are not part of a checkpoint, so there is no way to get a lower bound on the starting LSN needed to recover a local relation. In the past this did not matter, because either the local file would be (effectively) discarded during recovery because it had not yet become visible, or the file would be flushed before the transaction creating it made it visible. Now this is a problem. So I need a decision from the core team on what to do about the local buffer manager. My preference would be to forget about the local buffer manager entirely, or if not that then to allow it only for _true_ temporary data. The only alternative I can devise is to create some way for all other backends to participate in a checkpoint, perhaps using a signal. I'm not sure this can be done safely. Anyway, I'm glad the tuplesort stuff doesn't try to use relation files :-) Can the core team let me know if this is acceptable, and whether I should move ahead with changes to the buffer manager (and some other stuff) needed to avoid special treatment of rd_myxactonly relations? Also to Richard: have you guys at multera dealt with this issue already? Is there some way around this that I'm missing? Regards, John Nield Just as an example of this problem, imagine the following sequence: 1) Transaction TX1 creates a local relation LR1 which will eventually become a globally visible table. Tuples are inserted into the local relation, and logged to the WAL file. Some tuples remain in the local buffer cache and are not yet written out, although they are logged. TX1 is still in progress. 2) Backup starts, and checkpoint is called to get a minimum starting LSN (MINLSN) for the backed-up files. Only the global buffers are flushed. 3) Backup process copies LR1 into the backup directory. (postulate some way of coordinating with the local buffer manager, a problem I have not solved). 4) TX1 commits and flushes its local buffers. A dirty buffer exists whose LSN is before MINLSN. LR1 becomes globally visible. 5) Backup finishes copying all the files, including the local relations, and then flushes the log. The log files between MINLSN and the current LSN are copied to the backup directory, and backup is done. 6) Sometime later, a system administrator restores the backup and plays the logs forward starting at MINLSN. LR1 will be corrupt, because some of the log entries required for its restoration will be before MINLSN. This corruption will not be detected until something goes wrong. BTW: The problem doesn't only happen with backup! It occurs at every checkpoint as well, I just missed it until I started working on the hot backup issue. -- J. R. Nield [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(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] Trimming the Fat, Part Deux ...
Peter Eisentraut wrote: Bruce Momjian writes: Artistic License is fine, I think. The Artistic License doesn't even qualify as Free Software as far as the FSF is concerned. More generally, it is a different license, and that is a problem. Well, our ODBC is LGPL. I wonder if Edmund can/would change the license. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(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] Open 7.3 items
Marc G. Fournier wrote: I will object to any scheme that makes any characters in the user name magic. Two reasons: First, do it right, make a separate column. Second, several tools use URI syntax to specify data sources. This will break any feature that relies on being able to put special characters into the user name. The right solution to having database-local user names is putting extra information into pg_shadow regarding which database this user applies to. It could be an array or some separate authentication domain thing. OK, if you object, you can say goodbye to this feature for 7.3. I can supply the patch to Marc and anyone else who wants it but I am not inclined nor convinced we need that level of work for this feature. So we end up with nothing. Stupid qustion .. but why can't you just add a 'domain' column to pg_passwd/pg_shadow so that its stored as two fields instead of one? Which I believe is what Pter is/was suggesting ... Right now, pg_pwd only dumps users with passwords, and as I remember, it is only accessed when the protocol needs to lookup a password. It wasn't designed for anything more advanced. If you want separate columns, you have to dump out everyone, and modify CREATE USER, createuser, ALTER USER, ... to handle those new domain names, and you have to make this API visible to everyone even if they are not using domains. That's where things really get ugly. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Trimming the Fat, Part Deux ...
Lamar Owen wrote: On Thursday 01 August 2002 04:37 pm, Peter Eisentraut wrote: I thought we were talking about trimming the source tree, not adding more. Why not put it on gborg or somewhere else? It's already in CPAN. A link to CPAN should suffice, IMHO. I also thought we were discussing trimming the tree; and that was a good feeling. Lamar, you said earlier today: And the sooner our very old perl client goes away, the better I like it. It is a good client, don't get me wrong: but DBD:Pg is the standard now. So I assumed you wanted DBD:Pg. DBD:Pg is a good example of an interface that hasn't advanced a quickly as it would have had it been in our CVS tree. I have received a number of bug reports for it, and have them in my mailbox. I have no idea if they made it into the CPAN version. Moving interfaces out can be a problem too unless there is a large enough group to grow it. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] PITR, checkpoint, and local relations
On Thu, 2002-08-01 at 17:14, Bruce Momjian wrote: J.R needs comments on this. PITR has problems because local relations aren't logged to WAL. Suggestions? I'm sorry if it wasn't clear. The issue is not that local relations aren't logged to WAL, they are. The issue is that you can't checkpoint them. That means if you need a lower bound on the LSN to recover from, then you either need to wait for transactions using them all to commit and flush their local buffers, or there needs to be a async way to tell them all to flush. I am working on a way to do this with a signal, using holdoffs around calls into the storage-manager and VFS layers to prevent re-entrant calls. The local buffer manager is simple enough that it should be possible to flush them from within a signal handler at most times, but the VFS and storage manager are not safe to re-enter from a handler. Does this sound like a good idea? -- J. R. Nield [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] FUNC_MAX_ARGS benchmarks
Ok, here are some crude benchmarks to attempt to measure the effect of changing FUNC_MAX_ARGS. The benchmark script executed: CREATE FUNCTION test_func(int, int, int, int, int, int, int, int) RETURNS INTEGER AS 'SELECT $1 + $2 + $3 + $4 + $5 + $6 + $7 + $8' LANGUAGE 'sql' VOLATILE; Followed by 30,000 calls of: SELECT test_func(i, i, i, i, i, i, i, i); (Where i was the iteration number) I ran the test several times and averaged the results -- the wall-clock time remained very consistent throughout the runs. Each execution of the script took about 30 seconds. The machine was otherwise idle, and all other PostgreSQL settings were at their default values. With FUNC_MAX_ARGS=16: 28.832 28.609 28.726 28.680 (average = 28.6 seconds) With FUNC_MAX_ARGS=32: 29.097 29.337 29.138 28.985 29.231 (average = 29.15 seconds) Cheers, Neil -- Neil Conway [EMAIL PROTECTED] PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
