[HACKERS] How to do the modular test
Hi pgsql-hackers, Could anyone advise me how to do modular test in any partial PostgreSQL's modules? I am interested in the PostgreSQL development. I have begun study the DBMS source code by developer documentation provided by postgresql.org especially internal.ps that is the best explaination for developer beginner, I think. Moreover, the RedHat SourceNavigator I have found, is a great tools for me. Without it, I might not able to get more understanding of the PostgreSQL source code. Now I am concentrating on the Executor module. I plan to create a new Join Executor let's say ParallelJoin to enhance the Join operator processing. As this moment, I may use the HybridJoin algorithm implementing in the HashJoin module as my guidance but the NestLoop and MergeJoin may be considered in the furture. What I would like to know is, if I have changed some ot the modules, how can I use GNU gdb to debug the modified codes? I am sorry if the question is disturb your mailing list. I know this is not the issue related in your TODO list. However I have expected to your response. thanks and regards, Werachart. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Fast Forward (fwd)
On Sun, Apr 15, 2001 at 01:17:15AM -0400, Vince Vielhaber wrote: > > Here's my response to the inaccurate article cmp produced. After > chatting with Marc I decided to post it myself. > ... > Where do you get your info? Do you just make it up? PostgreSQL is > not a product of Great Bridge and never has been. It's 100% independant. > Is Linux a keyword you figure you can use to draw readers? Won't take > long before folks determine you're full of it. The PostgreSQL team takes > great pride (not to be confused with great bridge) in ensuring that the > work we do runs on ALL platforms; be it Mac's OSX, FreeBSD 4.3, or even > Windows 2000. So why do you figure this is a Great Bridge product? Why > do you figure it's Linux only? What is it with you writers lately? Are > you getting lazy and simply using Linux as a quick out for a paycheck? This is probably a good time to point out that this is the _worst_ _possible_ response to erroneous reportage. The perception by readers will not be that the reporter failed, but that PostgreSQL advocates are rabid weasels who don't appreciate favorable attention, and are dangerous to write anything about. You can bet this reporter and her editor will treat the topic very circumspectly (i.e. avoid it) in the future. When they have to mention it, their reporting will be colored by their personal experience. They (and their readers) don't run the code, so they must get their impressions from those who do. Most reporters are ignorant, most reporters are lazy, and many are both. It's part of the job description. Getting angry about it is like getting angry at birds for fouling their cage. Their job is to regurgitate what they're given, and quickly. They have no time to learn the depths, or to write coherently about it, or even to check facts. None of the errors in the article matter. Nobody will develop an enduring impression of PG from them. What matters is that PG is being mentioned in the same article with Oracle. In her limited way, she did the PG community the biggest favor in her limited power, and all we can do is attack? It will be harder than the original mailings, but I urge each who wrote to write again and apologize for attacking her. Thank her graciously for making an effort, and offer to help her check her facts next time. PostgreSQL needs friends in the press, even if they are ignorant or lazy. It doesn't need any enemies in the press. Nathan Myers [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Re: 7.1 RPMs
On Sun, 15 Apr 2001, Thomas Lockhart wrote: > > Do we need to start thinking about an RPM mailing list? Seems there is > > lots of traffic. > > The delete key is your friend. So is procmail, if you just can't stand > to see the letters "R", "P", and "M" too close together ;) > > I'm not a big fan of the trend to fork off a mailing list anytime more > than a few messages on a single topic come through. The synergy and > cross-pollination that we get by having us all see various topics wrt > development far outweigh the minor annoyance to some on having to delete > topics they don't find interesting. > > As an example, RPM building is only a part of the general packaging of > PostgreSQL, but it illustrates issues which anyone touching > configuration or Makefiles should be aware of. So forcing "those Linux > people" onto some specialty list weakens the knowledge base we all could > draw from. > > All imho of course... agreed, that's why I was kinda thinking maybe some sort of 'build' list ... something that deals with configure, makefile and packaging issues ... ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Re: 7.1 RPMs
Thomas Lockhart <[EMAIL PROTECTED]> writes: > I'm not a big fan of the trend to fork off a mailing list anytime more > than a few messages on a single topic come through. The synergy and > cross-pollination that we get by having us all see various topics wrt > development far outweigh the minor annoyance to some on having to delete > topics they don't find interesting. That's my feeling also. There's a considerable downside to fragmenting the PG discussions across multiple lists: not only that people may miss stuff that they should have seen, but also the increased probability that messages will be sent to the wrong lists to begin with. We should only split off new lists when the volume gets to the point of being absolutely intolerable --- which the RPM stuff is not. The Cygwin stuff might be sufficiently specialized that it can survive as a separate list, but I thought that was a marginal call at best. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Thankyou!
Tom and Peter, After looking at and thinking about the direction of the PostgreSQL project and the release of 7.1, I wanted to personally thank the both of you for your hard work and contributions to the project which without your efforts there might not only not be a 7.1, PostgreSQL might not be where it is at all. Knowing the both of you as I've been fortunate of, I know you're both rather modest but nonetheless are still deserving of my heartfelt thanks. Sincerely, Vince. -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 56K Nationwide Dialup from $16.00/mo at Pop4 Networking Online Campground Directoryhttp://www.camping-usa.com Online Giftshop Superstorehttp://www.cloudninegifts.com == ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Re: 7.1 RPMS...
> Where are the 7.1 rpms downloadable from? (even the RC based ones)? ftp://ftp.postgresql.org/pub/dev/... or ftp://ftp.postgresql.org/pub/binary/... ---(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
[HACKERS] Re: 7.1 RPMs
> Do we need to start thinking about an RPM mailing list? Seems there is > lots of traffic. The delete key is your friend. So is procmail, if you just can't stand to see the letters "R", "P", and "M" too close together ;) I'm not a big fan of the trend to fork off a mailing list anytime more than a few messages on a single topic come through. The synergy and cross-pollination that we get by having us all see various topics wrt development far outweigh the minor annoyance to some on having to delete topics they don't find interesting. As an example, RPM building is only a part of the general packaging of PostgreSQL, but it illustrates issues which anyone touching configuration or Makefiles should be aware of. So forcing "those Linux people" onto some specialty list weakens the knowledge base we all could draw from. All imho of course... - Thomas ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Re: 7.1 RPMs
> > In the past I have found that kaffe did not handle enough java code for > > my needs, but that was not for the JDBC driver. I am currently using > > jikes for my projects, and it produces *nice* code in my experience. > Jikes is open source, right? I know it is available for Red Hat (ships > with it on one of the applications CD's,IIRC.) How does a Jikes-built > JDBC sound to people? Ormaybe I don't understand the Java Way well > enough to decide. Gotta learn it a little For the RPM, you should be able to build JDBC with whatever compiler produces reliable, quality code. jikes is one good candidate imho. Not sure if the configure info for JDBC looks for choices of compiler, or if you can specify the compiler for the build. I can look into it, but am not sure how one interacts with ant (we are using ant to do the Java build now, right??) or if ant handles it already. - Thomas ---(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
[HACKERS] Fast Forward (fwd)
Here's my response to the inaccurate article cmp produced. After chatting with Marc I decided to post it myself. Since I know Ned reads this list, I formally request that he also insists PUBLICALLY that cmp correct their inaccuracies. I'm rather disappointed (for lack of a more descriptive word) that Bruce has not already done so. 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 == -- Forwarded message -- Date: Sun, 15 Apr 2001 00:30:20 -0400 (EDT) From: Vince Vielhaber <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Fast Forward Where do you get your info? Do you just make it up? PostgreSQL is not a product of Great Bridge and never has been. It's 100% independant. Is Linux a keyword you figure you can use to draw readers? Won't take long before folks determine you're full of it. The PostgreSQL team takes great pride (not to be confused with great bridge) in ensuring that the work we do runs on ALL platforms; be it Mac's OSX, FreeBSD 4.3, or even Windows 2000. So why do you figure this is a Great Bridge product? Why do you figure it's Linux only? What is it with you writers lately? Are you getting lazy and simply using Linux as a quick out for a paycheck? I rarely (if ever) sign my name as a member of the PostgreSQL team, but this time I'm making an exception 'cuze you crossed the line. I also very rarely get involved in this politlcal crap, but you've crossed the line on that as well. The ENTIRE PostgreSQL team awaits your WRITTEN apology as does every support organisation listed on the website. Vince Vielhaber - Webmaster for PostgreSQL.org ---(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] pg_dump compatibility with 7.0
Philip Warner <[EMAIL PROTECTED]> writes: > At the moment it has no idea what do do with aggregates (is there > anything?), and it assumes 'proisstrict' on functions. I'll take the blame for the aggregate issue ;-). SFUNC1/STYPE1/INITCOND1 in 7.0 equate to SFUNC/STYPE/INITCOND in 7.1. There is no 7.1 equivalent to 7.0's SFUNC2/STYPE2/INITCOND2 --- those have to be saved/restored separately if you are dumping a 7.0 database with intentions of restoring it to 7.0. On the other hand, if you are dumping 7.0 with an eye to restoring to 7.1, you could just as well raise an error if those fields are nonnull. Assuming 'proisstrict' for a 7.0 function seems reasonable. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Hey guys, check this out.
okay, I didn't get a copy of it ... :(
On Sun, 15 Apr 2001, Vince Vielhaber wrote:
>
> I rarely sign a note as the webmaster, I like to keep a low profile.
> I just sent the witch a note and made it a point to let her know who
> I am - and BCCd Marc. He can cross post it if he wishes. I also sent
> it to the editor of that rag.
>
> Vince.
>
>
>
> On Sun, 15 Apr 2001, The Hermit Hacker wrote:
>
> >
> > there is little, to nothing, factual about that whole article ...
> >
> > "Great Bridge essentially gives away its open-source database application
> > at little cost..."
> >
> > - thannk god I can get it completely for free, eh?
> >
> > "Great Bridge executives say their licensing costs for the software..."
> >
> > - someone want to tell me when they started charging licensing
> > costs?
> >
> > "...nearly 25 years ago"
> >
> > - I thought it was around '85? That's only 15 years ...
> >
> > "Version 7.1, due to ship at the end of June..."
> >
> > - should I pull what we've released? *raised eyebrow*
> >
> > "...is the marketing and channel arm for PostgreSQL"
> >
> > - they are?
> >
> > I wonder, is Great Bridge going to step up and correct the *several*
> > mis-conceptions that have been touted in their name? There were alot of
> > quotes from GB in there, so I wonder ... ?
> >
> > On Sat, 14 Apr 2001, Lamar Owen wrote:
> >
> > > http://www.crn.com/Sections/Fast_Forward/fast_forward.asp?ArticleID=25670
> > >
> > > Marc will be pleased to note that the PostgreSQL project came out of the
> > > FreeBSD project, and is Great Bridge's database. Gotta love
> > > journalistic license.
> > > --
> > > 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
> > >
> >
> > Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
> > Systems Administrator @ hub.org
> > primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
> >
> >
> > ---(end of broadcast)---
> > TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
> >
>
> --
> ==
> 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 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
>
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(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] Hey guys, check this out.
I rarely sign a note as the webmaster, I like to keep a low profile.
I just sent the witch a note and made it a point to let her know who
I am - and BCCd Marc. He can cross post it if he wishes. I also sent
it to the editor of that rag.
Vince.
On Sun, 15 Apr 2001, The Hermit Hacker wrote:
>
> there is little, to nothing, factual about that whole article ...
>
> "Great Bridge essentially gives away its open-source database application
> at little cost..."
>
> - thannk god I can get it completely for free, eh?
>
> "Great Bridge executives say their licensing costs for the software..."
>
> - someone want to tell me when they started charging licensing
> costs?
>
> "...nearly 25 years ago"
>
> - I thought it was around '85? That's only 15 years ...
>
> "Version 7.1, due to ship at the end of June..."
>
> - should I pull what we've released? *raised eyebrow*
>
> "...is the marketing and channel arm for PostgreSQL"
>
> - they are?
>
> I wonder, is Great Bridge going to step up and correct the *several*
> mis-conceptions that have been touted in their name? There were alot of
> quotes from GB in there, so I wonder ... ?
>
> On Sat, 14 Apr 2001, Lamar Owen wrote:
>
> > http://www.crn.com/Sections/Fast_Forward/fast_forward.asp?ArticleID=25670
> >
> > Marc will be pleased to note that the PostgreSQL project came out of the
> > FreeBSD project, and is Great Bridge's database. Gotta love
> > journalistic license.
> > --
> > 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
> >
>
> Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
> Systems Administrator @ hub.org
> primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
>
>
> ---(end of broadcast)---
> TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
>
--
==
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 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
[HACKERS] pg_dump compatibility with 7.0
I've been messing around with a 7.0 compatible dump for 7.1, and it looks good so far (at least I can dump & restore my local DBs and, to some extent, the regression DB, including BLOBs). It is a mixture of 7.1 and 7.0 features, in the sense that it is basically the 7.1 pg_dump but with 7.0 SQL/methods where necessary. As a result it dumps in OID order etc but has the 7.0 type formatting for 7.0 databases. It also uses pg_views to get the view definition, and, at least on 7.0.2, the view was mildly broken so the regression DB does not dump properly. I'd be interested in feedback etc, if people don't mind. The patch (against CVS) can be found at: ftp://ftp.rhyme.com.au/pub/postgresql/pg_dump/pg_dump_1504_patch.gz At the moment it has no idea what do do with aggregates (is there anything?), and it assumes 'proisstrict' on functions. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(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] Hey guys, check this out.
there is little, to nothing, factual about that whole article ...
"Great Bridge essentially gives away its open-source database application
at little cost..."
- thannk god I can get it completely for free, eh?
"Great Bridge executives say their licensing costs for the software..."
- someone want to tell me when they started charging licensing
costs?
"...nearly 25 years ago"
- I thought it was around '85? That's only 15 years ...
"Version 7.1, due to ship at the end of June..."
- should I pull what we've released? *raised eyebrow*
"...is the marketing and channel arm for PostgreSQL"
- they are?
I wonder, is Great Bridge going to step up and correct the *several*
mis-conceptions that have been touted in their name? There were alot of
quotes from GB in there, so I wonder ... ?
On Sat, 14 Apr 2001, Lamar Owen wrote:
> http://www.crn.com/Sections/Fast_Forward/fast_forward.asp?ArticleID=25670
>
> Marc will be pleased to note that the PostgreSQL project came out of the
> FreeBSD project, and is Great Bridge's database. Gotta love
> journalistic license.
> --
> 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
>
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Hey guys, check this out.
On Sat, 14 Apr 2001, Lamar Owen wrote: > http://www.crn.com/Sections/Fast_Forward/fast_forward.asp?ArticleID=25670 > > Marc will be pleased to note that the PostgreSQL project came out of the > FreeBSD project, and is Great Bridge's database. Gotta love > journalistic license. Oh, and 7.1's due to ship at the end of June... *cough* Somebody should forward Marc's announcement from last night to them. -- Dominic J. Eidson "Baruk Khazad! Khazad ai-menu!" - Gimli --- http://www.the-infinite.org/ http://www.the-infinite.org/~dominic/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[HACKERS] Hey guys, check this out.
http://www.crn.com/Sections/Fast_Forward/fast_forward.asp?ArticleID=25670 Marc will be pleased to note that the PostgreSQL project came out of the FreeBSD project, and is Great Bridge's database. Gotta love journalistic license. -- 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] Re: 7.1 RPMs
Peter Eisentraut wrote: > The traffic naturally peaks around release time, and this time especially > because yours truly messed up the whole build system that the packagers > were so careful to work around. Now, Peter. The build, IMHO, is much better than before -- if anything, the fact that we had to change as much as we did shows that the previous build system, no offense intended to anyone who worked on it :-), wasn't 'packaging friendly.' I ripped out more special treatment than I had to put in. The less code in the spec, the better the spec (and the better the package). Now I just have to get the Python build version-agnostic and using the regular build -- even if I have to dink with the makefiles myself. I think the perl build, due to its two-stage needs, will remain the special case that it is. > I trust that in a few weeks we'll enter a > new quiet period. My vote is that technical packaging discussions should > go on -hackers just like a makefile discussion. I tend to agree -- but at the same time I'm easy to get along with in that regard. Packaging envelopes the whole program -- I must see the forest that the -hackers group has built out of trees. And I have to know some details of the trees occasionally. I'm sure Oliver would agree. And, to let everyone know, I'm having a blast doing this. And I'm glad my work schedule eased up some in the last month so I could put some time to this task. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Re: 7.1 RPMs
The Hermit Hacker writes: > If someone wants to come up with an idea for name, i think that the whole > Win camp could be seperated also ... > > pgsql-windows and pgsql-rpm ? There seem to be a lot of Linux users, too. How about a new mailing list? -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: NetBSD "Bad address" failure (was Re: [HACKERS] Third call for platform testing)
Tom Ivar Helbekkmo <[EMAIL PROTECTED]> writes: > I can verify, that with NetBSD-current on sparc, your test code works > the way you want it to on local disk, but fails (in the way you've > observed), if the target file is on an NFS-mounted file system. FWIW, the test program succeeds (no error) using HPUX 10.20 and a couple different Linux flavors as either client or server. So I'm still thinking that it's NetBSD-specific. It would be useful to try it on some other BSD derivatives though ... 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: NetBSD "Bad address" failure (was Re: [HACKERS] Third call for platform testing)
Tom Lane <[EMAIL PROTECTED]> writes: > > I think this is indisputably a bug in (some versions of) NetBSD. > > I forgot to mention a possible contributing factor: the files involved > were NFS-mounted, in the case I was looking at. So this may be an NFS > problem more than a NetBSD problem. Anyone want to try the given test > case on NFS-mounted files on other systems? I can verify, that with NetBSD-current on sparc, your test code works the way you want it to on local disk, but fails (in the way you've observed), if the target file is on an NFS-mounted file system. -tih -- The basic difference is this: hackers build things, crackers break them. ---(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
[HACKERS] alter database without shutting down !?
first, congratulations to all for the 7.1 release, good work. second, I've found (some years ago to be honest) that pgsql can ALTER TABLE while the table is widely available for all users... this strike me as pretty bad/dangerous/confusing/messy (even from the POV of implementation) should I supposed to do something like: ALTER DATABASE CLOSE or ALTER DATABASE SHUTDOWN [options] (simil oracle) before doing changes to the definition of tables ? someone can say this is a feature, don't think so, even then I think that ALTER TABLE DROP COLUMN could be implemented a *lot* more easily with this method. (and requiring this operation to enter DDL sound very logical) regards, sergio _ ¿Lo probaste? Correo gratis y para toda la vida en http://correo.yahoo.com.ar ---(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] Re: 7.1 RPMs
> The Hermit Hacker <[EMAIL PROTECTED]> writes: > > I like Lamar's suggestion of pgsql-cygwin though ... sound reasonable? > > Yes, that's probably better than pgsql-windows ... But then again, the comment this is more properly done on ports makes sense. -- 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] Name -> number ...
The Hermit Hacker <[EMAIL PROTECTED]> writes: > 77 databases in data/base directory ... all number'd ... > select * from pg_database; > doesn't give me the reference to which directory is which database ... so > what table do we need to join on to get this information? select oid, datname from pg_database; I think Bruce did a contrib utility to keep track of this, too. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Re: 7.1 RPMs
On Sat, 14 Apr 2001, Tom Lane wrote: > The Hermit Hacker <[EMAIL PROTECTED]> writes: > > I like Lamar's suggestion of pgsql-cygwin though ... sound reasonable? > > Yes, that's probably better than pgsql-windows ... Done ... ---(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] Re: 7.1 RPMs
On Sat, 14 Apr 2001, Peter Eisentraut wrote: > The Hermit Hacker writes: > > > I like Lamar's suggestion of pgsql-cygwin though ... sound reasonable? > > We have pgsql-ports, which isn't seeing too much traffic as it is. Seems > like the cygwin people hang out there anyway. Ya, well, there is alot of traffic on -hackers that should probably be over there anyway *shrug* ---(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] Re: 7.1 RPMs
On Sat, 14 Apr 2001, The Hermit Hacker wrote: > On Sat, 14 Apr 2001, Peter Eisentraut wrote: > > > Bruce Momjian writes: > > > > > Do we need to start thinking about an RPM mailing list? Seems there is > > > lots of traffic. > > > > The traffic naturally peaks around release time, and this time > > especially because yours truly messed up the whole build system that > > the packagers were so careful to work around. I trust that in a few > > weeks we'll enter a new quiet period. My vote is that technical > > packaging discussions should go on -hackers just like a makefile > > discussion. > > Why not a "pgsql-build", or something like that, list? Where build/make > file discussions can take place? Vs server issues? I'd really like to > find some way of reducing traffic on -hackers like we did with -interfaces > ... if we can come up with a good list for it ... > > pgsql-build (or a better name?) could be for RPM discussions, just as easy > as Makefile/Configure discussions ... How 'bout pgsql-hackers-rpm. Because the make/config stuff can impact so many different parts of PostgreSQL, that stuff should probably remain on hackers. 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 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Name -> number ...
d'oh, should have extended my query ...
select oid,* from pg_database;
gives the directory name ...
thanks :)
On Sat, 14 Apr 2001, Bruce Momjian wrote:
> >
> > 77 databases in data/base directory ... all number'd ...
> >
> > select * from pg_database;
> >
> > doesn't give me the reference to which directory is which database ... so
> > what table do we need to join on to get this information?
> >
> > thanks ...
>
> Info is in pg_class.relfilenode. Now the big question is where do
> database names go. My guess is pg_database.oid.
>
> --
> 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
>
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(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] Name -> number ...
> > 77 databases in data/base directory ... all number'd ... > > select * from pg_database; > > doesn't give me the reference to which directory is which database ... so > what table do we need to join on to get this information? > > thanks ... Info is in pg_class.relfilenode. Now the big question is where do database names go. My guess is pg_database.oid. -- 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] Re: 7.1 RPMs
The Hermit Hacker writes: > I like Lamar's suggestion of pgsql-cygwin though ... sound reasonable? We have pgsql-ports, which isn't seeing too much traffic as it is. Seems like the cygwin people hang out there anyway. -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ---(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] Name -> number ...
> > d'oh, should have extended my query ... > > select oid,* from pg_database; > > gives the directory name ... > Interesting to not that reffilenode is for tables, but oid is for databases. I hadn't realized that distinction until you asked. You can't rename databases, so the oid is OK for this. -- 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://www.postgresql.org/search.mpl
Re: [HACKERS] Re: 7.1 RPMs
The Hermit Hacker <[EMAIL PROTECTED]> writes: > I like Lamar's suggestion of pgsql-cygwin though ... sound reasonable? Yes, that's probably better than pgsql-windows ... 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
[HACKERS] 7.1 RPMS...
Where are the 7.1 rpms downloadable from? (even the RC based ones)? Chris Bowlby, - Web Developer @ Hub.org. [EMAIL PROTECTED] www.hub.org 1-902-542-3657 - ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Re: 7.1 RPMs
On Sat, 14 Apr 2001, Peter Eisentraut wrote: > Bruce Momjian writes: > > > Do we need to start thinking about an RPM mailing list? Seems there is > > lots of traffic. > > The traffic naturally peaks around release time, and this time > especially because yours truly messed up the whole build system that > the packagers were so careful to work around. I trust that in a few > weeks we'll enter a new quiet period. My vote is that technical > packaging discussions should go on -hackers just like a makefile > discussion. Why not a "pgsql-build", or something like that, list? Where build/make file discussions can take place? Vs server issues? I'd really like to find some way of reducing traffic on -hackers like we did with -interfaces ... if we can come up with a good list for it ... pgsql-build (or a better name?) could be for RPM discussions, just as easy as Makefile/Configure discussions ... ---(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] Re: 7.1 RPMs
> Bruce Momjian writes: > > > Do we need to start thinking about an RPM mailing list? Seems there is > > lots of traffic. > > The traffic naturally peaks around release time, and this time especially > because yours truly messed up the whole build system that the packagers > were so careful to work around. I trust that in a few weeks we'll enter a > new quiet period. My vote is that technical packaging discussions should > go on -hackers just like a makefile discussion. > OK, it was just an idea. -- 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] Re: 7.1 RPMs
Bruce Momjian writes: > Do we need to start thinking about an RPM mailing list? Seems there is > lots of traffic. The traffic naturally peaks around release time, and this time especially because yours truly messed up the whole build system that the packagers were so careful to work around. I trust that in a few weeks we'll enter a new quiet period. My vote is that technical packaging discussions should go on -hackers just like a makefile discussion. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Re: 7.1 RPMs
On Sat, 14 Apr 2001, Tom Lane wrote: > The Hermit Hacker <[EMAIL PROTECTED]> writes: > > If someone wants to come up with an idea for name, i think that the whole > > Win camp could be seperated also ... > > > pgsql-windows and pgsql-rpm ? > > A windows list seems like a good idea. But I'm not sure that a > separate list for RPMs is a good idea. In the first place, it's > fuzzy: is it to be used just for RPM packaging discussion, or is it > going to draw off --- for example --- all bug reports from people who > happen to have installed from RPM instead of source? I suppose the > former is intended, but it's not going to be clear to people. I think > we've already got too many lists with fuzzy boundaries. In the second > place, the RPM packaging discussion is quite sporadic; I think the > traffic would be nil except at times when Lamar is working on new > RPMs. That's why I wasn't sure how to classify the RPM one ... I like Lamar's suggestion of pgsql-cygwin though ... sound reasonable? ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Re: 7.1 RPMs
The Hermit Hacker <[EMAIL PROTECTED]> writes: > If someone wants to come up with an idea for name, i think that the whole > Win camp could be seperated also ... > pgsql-windows and pgsql-rpm ? A windows list seems like a good idea. But I'm not sure that a separate list for RPMs is a good idea. In the first place, it's fuzzy: is it to be used just for RPM packaging discussion, or is it going to draw off --- for example --- all bug reports from people who happen to have installed from RPM instead of source? I suppose the former is intended, but it's not going to be clear to people. I think we've already got too many lists with fuzzy boundaries. In the second place, the RPM packaging discussion is quite sporadic; I think the traffic would be nil except at times when Lamar is working on new RPMs. 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] Re: 7.1 RPMs
The Hermit Hacker wrote: > If someone wants to come up with an idea for name, i think that the whole > Win camp could be seperated also ... > pgsql-windows and pgsql-rpm ? > as far as newsgroups are concerned, they would both fall under ports: If that's what you want to do. Although, I'd recommend pgsql-cygwin, lest someone erroneously think we directly support Win32. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[HACKERS] Name -> number ...
77 databases in data/base directory ... all number'd ...
select * from pg_database;
doesn't give me the reference to which directory is which database ... so
what table do we need to join on to get this information?
thanks ...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Re: 7.1 RPMs
If someone wants to come up with an idea for name, i think that the whole
Win camp could be seperated also ...
pgsql-windows and pgsql-rpm ?
as far as newsgroups are concerned, they would both fall under ports:
comp.databases.postgresql.ports.linux.rpm
comp.databases.postgresql.ports.windows
I'm willing to create, as long as ppl are willing to use *shrug*
On Sat, 14 Apr 2001, Bruce Momjian wrote:
> Do we need to start thinking about an RPM mailing list? Seems there is
> lots of traffic.
>
> --
> 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])
>
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
Re: [HACKERS] Re: Possible explanation for readline configuration problems
Peter Eisentraut <[EMAIL PROTECTED]> writes: > (b) the readline dudes commented out (#if 0) the declaration of > filename_completion_function in the header in favour of the new > rl_filename_completion_function (but left the symbol in the library). The "#if 0" silliness is not what's confusing configure however, because what it's grepping is preprocessor output; it will not see the commented-out declaration of filename_completion_function. What it *does* see is the declaration of rl_filename_completion_function, and because of the lack of defense against partial-word matches, mistakes that for filename_completion_function. Our code would actually work if AC_EGREP_HEADER weren't so nonrobust about what it will take as a match. > Needless to say, the readline developers deserve to be shot for doing this > in a minor release. I don't suppose our life would be any simpler if they'd called it 5.0 instead of 4.2, though. Visions of mayhem aside, we ought to try to persuade our code to work cleanly with 4.2 as well as earlier releases. Do you have time to work on that for 7.1.1 (ie, end of the month or so)? regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] pg_dump ordering problem (rc4)
Philip Warner <[EMAIL PROTECTED]> writes: > I don't suppose we can change the pg_views view without an initdb? No, not very readily. Even assuming that we were willing to require dbadmins to run a script during upgrade (which I wouldn't want to do unless forced to it), it's not that easy to fix all the occurrences of a system view. Remember there will be a separate copy in each database, including template0 which you can't even get to. On top of which, DROP VIEW/CREATE VIEW wouldn't work because the view would then have the wrong OID, and would look like a user-created object to pg_dump. You'd have to manually manipulate tuples in pg_class, pg_attribute, pg_rewrite, etc. Kluging pg_dump is a *lot* cleaner. I agree with the idea of adding the rule OID as a new column of pg_views for 7.2, however. 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] Re: 7.1 RPMs
Do we need to start thinking about an RPM mailing list? Seems there is lots of traffic. -- 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] Re: 7.1 RPMs
Lamar Owen <[EMAIL PROTECTED]> writes: > > In the past I have found that kaffe did not handle enough java code for > > my needs, but that was not for the JDBC driver. I am currently using > > jikes for my projects, and it produces *nice* code in my experience. > > Jikes is open source, right? I know it is available for Red Hat (ships > with it on one of the applications CD's,IIRC.) How does a Jikes-built > JDBC sound to people? Ormaybe I don't understand the Java Way well > enough to decide. Gotta learn it a little Jikes is an excellent compiler, but it needs a set of classes to compile against from a JDK. -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Re: 7.1 RPMs
Thomas Lockhart wrote: > I believe that there is no room for -ffast-math in PostgreSQL. The I have placed code in the spec to strip out ffast-math from the CFLAGS. I have not as yet followed Peter's advice on exporting CFLAGS and leaving COPT -- but that's not to say that I won't. > > While I don't plan on following the Mandrake Way WRT repackaging our > > tarball with bzip2, the source RPM should use whatever compression for > > the man pages that the buildrootpolicy for that distribution supplies. > Certainly so for the tarball. However the tarballs are delivered is how > we should use them imho. Exactly. > them uncompressed in the RPM build area then they get compressed by RPM > somewhere between installation and RPM packaging, right? Right. Each distributor can use its own buildrootpolicy -- which handles man page compression, executable stripping, and the like. Not an issue -- but Mandrake historically bzip2's them. > Not sure about the python stuff, and I don't recall doing anything in > the past on that topic. I thought you did up the current build way ... but I could be mistaken. I need to see if the python interface makefile Does the Right Thing now WRT RPM_BUILD_ROOT/DESTDIR processing. The main make stuff now acts sanely inthe presence of RPM_BUILD_ROOT -- well, except the perl interface, but that's a special case. > In the past I have found that kaffe did not handle enough java code for > my needs, but that was not for the JDBC driver. I am currently using > jikes for my projects, and it produces *nice* code in my experience. Jikes is open source, right? I know it is available for Red Hat (ships with it on one of the applications CD's,IIRC.) How does a Jikes-built JDBC sound to people? Ormaybe I don't understand the Java Way well enough to decide. Gotta learn it a little -- 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
[HACKERS] Re: 7.1 RPMs
> I haven't addressed that as yet. Is it safe to assume that -ffast-math > should be Considered Harmful in the RPM_OPT_FLAGS? Is -ffast-math > _ever_ a Good Thing for our routines? I can easily enough strip out > -ffast-math from the flags for all cases (xarg -n 1 grep -v > ffast-math|xargs is your friend). I believe that there is no room for -ffast-math in PostgreSQL. The compiler man page says that the option allows the compiler to generate code which does not conform to IEEE math standards, and istm that we might consider that as affecting our predictability and portability. The man page also warns against using -ffast-math and -O together, but I can't tell if that is a warning to users or a "note to myself" for the compiler maintainers. > While I don't plan on following the Mandrake Way WRT repackaging our > tarball with bzip2, the source RPM should use whatever compression for > the man pages that the buildrootpolicy for that distribution supplies. Certainly so for the tarball. However the tarballs are delivered is how we should use them imho. Why is it an issue for the man pages? They are uncompressed in our source tarball (? haven't checked) and if we have them uncompressed in the RPM build area then they get compressed by RPM somewhere between installation and RPM packaging, right? > > How are you planning on packaging the hardcopy docs? They are not yet > > available, but will be Real Soon Now :( > In the postgresql-docs subpackage, along with the SGML source. The html > built docs made from the SGML source is still going into the main > tarball, as they are nice and browseable in their standard location. > If I release a -1 RPM without the hardcopy, I can release a -2 with Great. > There's also a question about the Python client -- it would be good if > someone who has downloaded one of the RC RPM's could test that, as I'm > not a snake charmer. :-) Not sure about the python stuff, and I don't recall doing anything in the past on that topic. > Also, I need either a standard way to build the java stuff (meaning my > own JDK that is reasonably standard by consensus -- kaffe ships with > RedHat 7.0 -- isthat an acceptable JDK-substitute?) or someone needs to > package 7.1 JDBC jars for my packaging pleasure. I'm running low enough > on disk space on my devel machines (one of which is a notebook) to make > my own JDK a second choice. In the past I have found that kaffe did not handle enough java code for my needs, but that was not for the JDBC driver. I am currently using jikes for my projects, and it produces *nice* code in my experience. - Thomas ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] pg_dump, formats & blobs
At 04:10 14/04/01 +0200, Mathijs Brands wrote: > >Sorry about the false alarm. I was convinced restoring blobs >didn't work correctly. > The tar problem is now fixed in CVS. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] pg_dump ordering problem (rc4)
At 17:34 13/04/01 -0400, Tom Lane wrote: > >A possible kluge answer is to make pg_dump's OID-ordering of views >depend on the OID of the view rule rather than the view relation. >I am not sure if that would break any cases that work now, however. > Fixed in CVS. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(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] pg_dump ordering problem (rc4)
At 18:29 14/04/01 +1000, Philip Warner wrote: > >I don't suppose we can change the pg_views view without an initdb? > Having now looked at the source, I realize that initdb is where this view is defined. However, is there any reason that we can not change this definition when upgrading to 7.1.1? The embargo on initdb is, I think, primarily related to avoiding export/import of databases - is that right? If so, then doing non-destructive changes to things like system views does not seem too evil (in this case an update of a row of pg_rewrite and the addition of an attr to pg_views, I think). Am I missing something here? ISTM that the more higher level definitions we have (eg. functions returning multiple rows, DEFINITION SCHEMAs etc), the more we may need to allow changes to be made of things that are *customarily* defined in initdb. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Re: Possible explanation for readline configuration problems
Tom Lane writes: > We've gotten several different reports lately of peculiar compilation > errors and warnings involving readline in 7.1. They look like configure > is actively doing the wrong thing --- for example, how could we see > reports like this: > > tab-complete.c:734: `filename_completion_function' undeclared (first use in this >function) > tab-complete.c:734: (Each undeclared identifier is reported only once > tab-complete.c:734: for each function it appears in.) > > when the code makes a point of providing a declaration for > filename_completion_function if configure didn't see it in the headers? Because (a) the readline dudes changed the type of filename_completion_function in version 4.2 from extern char *filename_completion_function __P((char *, int)); to extern char *filename_completion_function __P((const char *, int)); and (b) the readline dudes commented out (#if 0) the declaration of filename_completion_function in the header in favour of the new rl_filename_completion_function (but left the symbol in the library). Other symbols were treated similarly, leading to implicit declarations with ints. Needless to say, the readline developers deserve to be shot for doing this in a minor release. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] RPM upgrade caveats going from a beta version to RC
"Len Morgan" wrote: >>> Lamar Owen writes: >>> >>> > One quick note -- since 'R' < 'b', the RC RPM's must be forced to >>> > install with --oldpackage, as RPM does a simple strcmp of version >>> > numbers -- 7.1RC3 < 7.1beta1, for instance. Just force it with >>> > --oldpackage if you have a 7.1beta RPM already installed. > >Couldn't this be fixed (in future releases) with rcX and BetaX? I believe >r > B. or, for that matter, by betaX rcX. But we have still gone from rc4 to nothing in the just-released 7.1, which is backward as far as packaging systems are concerned. $ dpkg --compare-versions 7.1 gt 7.1rc4 || echo BSD style does not work! BSD style does not work! Marc, _please_ make the next release greater than its betas! As far as Debian is concerned, 7.1 will be known as 7.1release. Sigh... -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight http://www.lfix.co.uk/oliver PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47 GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C "Be strong, and let your heart take courage, all you who hope in the Lord." Psalm 31:24 ---(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] pg_dump ordering problem (rc4)
At 03:53 14/04/01 -0400, Tom Lane wrote: > >> Would people mind me adding a 'pg_getviewoid()' for pg_dump's use? > >While that would be a clean solution, it would mean that the problem >will remain until 7.2, because you don't get to assume another initdb >until 7.2. I don't think we want to wait that long; I want to see a fix >of some kind in 7.1.1. > >A possible compromise is to do a direct lookup of the OID in 7.1.* >with plans to replace it with some backend-side solution in 7.2 and >beyond. > I don't suppose we can change the pg_views view without an initdb? If so, a better solution would be to add a 'view_oid' column. Otherwise, I'll have to kludge pg_dump. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] pg_dump ordering problem (rc4)
Philip Warner <[EMAIL PROTECTED]> writes: > Having now looked at pg_dump more closely, I'm not at all sure I want to > make the change directly in pg_dump. The reason is that I am trying to move > version-specific stuff from pg_dump, and I currently get a view definition > by doing 'select pg_getviewdef()' (rather than looking up the rule etc). > Would people mind me adding a 'pg_getviewoid()' for pg_dump's use? While that would be a clean solution, it would mean that the problem will remain until 7.2, because you don't get to assume another initdb until 7.2. I don't think we want to wait that long; I want to see a fix of some kind in 7.1.1. A possible compromise is to do a direct lookup of the OID in 7.1.* with plans to replace it with some backend-side solution in 7.2 and beyond. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] pg_dump ordering problem (rc4)
>>> > >>> >A possible kluge answer is to make pg_dump's OID-ordering of views >>> >depend on the OID of the view rule rather than the view relation. >>> >I am not sure if that would break any cases that work now, however. >>> > >>> >>> This seems good to me; it should be based on the 'oid of the view', and >>> AFAICT, the rule OID should be it. Should I do this? >> >>The view oid is certainly better than the base relation oid. >> > >Since I'm in pg_dump at the moment, I'll make the change... > Having now looked at pg_dump more closely, I'm not at all sure I want to make the change directly in pg_dump. The reason is that I am trying to move version-specific stuff from pg_dump, and I currently get a view definition by doing 'select pg_getviewdef()' (rather than looking up the rule etc). Would people mind me adding a 'pg_getviewoid()' for pg_dump's use? (especially since 7.1 now seems to be out...) Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] cvs postgres doesn't compile with libreadline 4.2
andrea gelmini writes: > debian unstable, i386. > upgrade libreadline 4.2 > postgres doesn't compile. It seems there were some incompatible changes in readline 4.2. Use version 4.1 until we have a fix. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Upgrade complete ... all went smooth ...
Just as an FYI for those considering the shift ... I just upgraded all of
my databases over to v7.1 from v7.0.3 and it was smooth as silk. The only
problems were having to compile and load a few modules from contrib that
some of my clients were using ...
Took about an hour and a half to do >100 databases ..
Very impressive ...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(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
