Re: [PATCHES] Adding fulldisjunctions to the contrib
On 8/26/06, Andrew Dunstan <[EMAIL PROTECTED]> wrote: So, yes, it is used, and by far more that just hard core hackers. OK. Kewl. I just hadn't run into many people (except hackers) that knew about it. Thanks for sharing that. -- Jonah H. Harris, Software Architect | phone: 732.331.1300 EnterpriseDB Corporation| fax: 732.331.1301 33 Wood Ave S, 2nd Floor| [EMAIL PROTECTED] Iselin, New Jersey 08830| http://www.enterprisedb.com/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] Adding fulldisjunctions to the contrib
Jonah H. Harris wrote: On 8/26/06, Joshua D. Drake <[EMAIL PROTECTED]> wrote: Your attitude has been lacking about this whole thing, as has a lot of other people. PgFoundry is the official sub project site for PostgreSQL. That may be the case. However, all I've seen+heard is conjecture that pgfoundry is a good thing; where's the proof? Show me and other fellow "whiners" that a lot of people use pgfoundry and I'll gladly shut up about it. true story. I walked into my new boss's office the other day. He knew I was connected with PostgreSQL (after all, that's why he gave me the job), but we had never discussed pgfoundry - in fact he was very surprised yesterday to hear I had anything to do with it. But that day his browser was open on the pgfoundry home page. So, yes, it is used, and by far more that just hard core hackers. cheers andrew ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Adding fulldisjunctions to the contrib
On 8/26/06, Joshua D. Drake <[EMAIL PROTECTED]> wrote: Your attitude has been lacking about this whole thing, as has a lot of other people. PgFoundry is the official sub project site for PostgreSQL. That may be the case. However, all I've seen+heard is conjecture that pgfoundry is a good thing; where's the proof? Show me and other fellow "whiners" that a lot of people use pgfoundry and I'll gladly shut up about it. It is not a graveyard, projects on PgFoundry should receive full advocacy and promotion about their abilities and their linkage PostgreSQL. See previous email to Andrew regarding projects that don't work with the latest versions of PostgreSQL. I think I've even seen a pgfoundry project last updated for 7.x; that's certainly the case for gborg. If we spent half as much time promoting and helping the various sub project succeed as we doing whining on this list, we would be far more dominant in the industry then we are. So, subprojects [pgfoundry] is the source of all industry dominance? I wish I would've known that before :) Sorry, I was itchin' to say it. I am sick of all the moaning that goes on, So am I... in general. When full disjunctons is ready, I am sure it will be considered for core. It currently is not and pgFoundry is the perfect place for until until then. As it's not a common feature, I don't think many of the hackers know what it is or what it does. Certainly, very few have spoken on this thread. It's odd, only 10 people have commented on this thread; 4 of which are core members, 2 in favor and 2 against. Yet, we're having an argument on why this wasn't included. Unless this is the new math, 2 vs. 2 seems like a tie to me. We can still promote and announce we have a full disjunctions implementation, just as we can advertise we have full text indexing. Wherever it ends up, I look forward to seeing the promotion and announcements. Tzahi has put a lot of work into it over the past few months. I'm done on this topic but would gladly appreciate public or private proof regarding pgfoundry's popularity. -- Jonah H. Harris, Software Architect | phone: 732.331.1300 EnterpriseDB Corporation| fax: 732.331.1301 33 Wood Ave S, 2nd Floor| [EMAIL PROTECTED] Iselin, New Jersey 08830| http://www.enterprisedb.com/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Adding fulldisjunctions to the contrib
On 8/26/06, Andrew Dunstan <[EMAIL PROTECTED]> wrote: this is inaccurate, irresponsible and insulting to those of us who spend time maintaining pgfoundry. Andrew, I'm sorry if it sounded that way... it wasn't meant as such. It is not a graveyard. Plenty of stuff outside the core gets included in packaged distributions - just see for example what goes into the Windows distro, or the packages that CP distributes. I'm not saying that *everything* on pgfoundry is junk... but I can start naming dead projects if you'd like. It's like SourceForge before SourceForge jumped the shark... now 90% of SourceForge is either projects dead-and-gone or which hadn't even started. It's almost not even worth the time to search SF.net anymore. I believe that's the direction pgfoundry is headed. Not because of poor management or administration... just that when you have a large number of projects, the majority of which are dead or not even worth viewing, it takes the credibility of the site down as a whole. Look at gborg... there was some good stuff there and there still is; if you already know about it. Both gborg and pgfoundry have projects on there won't even work with a current version of PostgreSQL. Outside of all us hackers... how many people actually use pgfoundry? Does anyone have the stats? Has anyone polled users? How many of the users are newbies and how many are already familiar with PostgreSQL? If we don't have these basic answers, continuing to praise pgfoundry as the home for all-things-PostgreSQL is pointless. The implication of your statement is that anything not accepted into the core is automatically somehow considered unworthy. Not at all. I'm referring to this case in particular. Please refer to Tom's recent remarks about playing on extensibility as one of our strengths. I never said it wasn't... extensibility is, IMHO, our *core* strength. However, I don't think that's a good reason for pushing everything to pgfoundry. My impression (please correct me if I'm wrong) is that proper full disjunction support would include grammar support, in which case contrib is not where it should belong anyway. If that's so, then the next step would be for somebody to pick up the work that Tzahi has done and take it the rest of the way. That would be a worth goal for 8.3. You are correct, a *full* implementation would most likely include integration into the core; grammar and all. However, being as it's an entirely new feature in any database system ever seen, I don't think it should be required. It's kind of funny though; it's difficult enough to convince -hackers to adopt a feature that every other database system in the world has, yet we're going to make it even more difficult for an innovative feature. I can only imagine trying to get a consensus on the grammar and implementation of a totally nonstandard feature that only a few people really understand. As I see it, the full disjunction code will likely end up being a low profile project on pgfoundry because Tzahi won't have time to continue maintaining it and not many of us have enough insight into it to do so ourselves. As such, I don't think it's going to get enough attention and enough of a user following to make it worth the time of one of the core developers to pick it up. Of course, I may always be wrong. Perhaps pgfoundry is more popular than I've seen in past experience. Maybe one of the core developers does want to pick up full disjunctions for 8.3. Guess we'll just have to wait and see... -- Jonah H. Harris, Software Architect | phone: 732.331.1300 EnterpriseDB Corporation| fax: 732.331.1301 33 Wood Ave S, 2nd Floor| [EMAIL PROTECTED] Iselin, New Jersey 08830| http://www.enterprisedb.com/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] [HACKERS] Performance testing of COPY (SELECT) TO
Bruce Momjian írta: Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches It will be applied as soon as one of the PostgreSQL committers reviews and approves it. Thanks. Would you please add this instead? psql built-in \copy (select ...) now also work. Best regards, Zoltán Böszörményi pgsql-copyselect-8.patch.gz Description: Unix tar archive ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] Updatable views
- Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: 25.08.2006 00:50:59 Subject: Re: [PATCHES] Updatable views > > Minor suggestion: change get_view_qualification_function to look the > function by Oid rather than name. I wasn't sure it was actually a good > idea to use a function that way, but if it's going to stay ... > > Another: remove create_nothing_rule, replace with call to > create_rule_stmt. > > Another: change hasRule to return a bool instead of an Oid. > > Another: instead of a comment like this: > > /* > * XXX It seems to me that these checks are not necessary; and further, > * they are useless. This is because the view is just being created, > * thus it cannot have any rules before the ones we are going to > * create. > * > * XXX What about CREATE OR REPLACE VIEW ??? > */ > > have a single paragraph explaining why the replace flag is needed. > Okay, i'll sent a reworked version asap, but can't get to it before monday. I'm away from my machine this weekend and have only sporadic access to my email. Bernd ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] Adding fulldisjunctions to the contrib
this is inaccurate, irresponsible and insulting to those of us who spend time maintaining pgfoundry. It is not a graveyard. Plenty of stuff outside the core gets included in packaged distributions - just see for example what goes into the Windows distro, or the packages that CP distributes. Jonah, Your attitude has been lacking about this whole thing, as has a lot of other people. PgFoundry is the official sub project site for PostgreSQL. It is not a graveyard, projects on PgFoundry should receive full advocacy and promotion about their abilities and their linkage PostgreSQL. If we spent half as much time promoting and helping the various sub project succeed as we doing whining on this list, we would be far more dominant in the industry then we are. I am sick of all the moaning that goes on, with this list about -- "oh please, we need this in core". It is a crock we have a huge repository of PostgreSQL projects that are not in core and this attitude is detrimental and negative to all who are involved with those projects. When full disjunctons is ready, I am sure it will be considered for core. It currently is not and pgFoundry is the perfect place for until until then. We can still promote and announce we have a full disjunctions implementation, just as we can advertise we have full text indexing. Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] Adding fulldisjunctions to the contrib
Jonah H. Harris wrote: On 8/25/06, Bruce Momjian <[EMAIL PROTECTED]> wrote: Sorry, we did not get enough feedback to include this in 8.2. Please add it to pgfoundry and let's see how it goes. Yep... it's too bad. A new feature no other database has now goes to it's final resting place on pgfoundry. Jonah, this is inaccurate, irresponsible and insulting to those of us who spend time maintaining pgfoundry. It is not a graveyard. Plenty of stuff outside the core gets included in packaged distributions - just see for example what goes into the Windows distro, or the packages that CP distributes. The implication of your statement is that anything not accepted into the core is automatically somehow considered unworthy. Please refer to Tom's recent remarks about playing on extensibility as one of our strengths. My impression (please correct me if I'm wrong) is that proper full disjunction support would include grammar support, in which case contrib is not where it should belong anyway. If that's so, then the next step would be for somebody to pick up the work that Tzahi has done and take it the rest of the way. That would be a worth goal for 8.3. cheers andrew ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] Adding fulldisjunctions to the contrib
On 8/25/06, Bruce Momjian <[EMAIL PROTECTED]> wrote: Sorry, we did not get enough feedback to include this in 8.2. Please add it to pgfoundry and let's see how it goes. Yep... it's too bad. A new feature no other database has now goes to it's final resting place on pgfoundry. -- Jonah H. Harris, Software Architect | phone: 732.331.1300 EnterpriseDB Corporation| fax: 732.331.1301 33 Wood Ave S, 2nd Floor| [EMAIL PROTECTED] Iselin, New Jersey 08830| http://www.enterprisedb.com/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [PATCHES] log_statement output for protocol
On 8/7/06, Bruce Momjian <[EMAIL PROTECTED]> wrote: Updated patch attached. It prints the text bind parameters on a single detail line. I still have not seen portal names generated by libpq. I'm currently testing CVS tip to generate sample log files. I noticed that Bruce only patched log_statement and not log_min_duration_statement which still has the old behaviour ie: [1-1] LOG: duration: 0.097 ms execute my_query: SELECT * FROM shop WHERE name = $1 The problem of not having the bind parameters still remains. A lot of people use log_min_duration_statement and it's usually recommended to use it instead of log_statement because log_statement generates far too much output. I tried to find a way to fix it but it's not so simple as when we bind the statement, we don't know if the query will be slower than log_min_duration_statement. My first idea is that we should add a DETAIL line with the parameter values to the execute log line when we are in the log_min_duration_statement case. AFAICS the values are in the portal but I don't know the overhead introduced by generating the detail line from the portal. Does anyone have a better idea on how we could fix it? Regards, -- Guillaume ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
