Re: Removing Libraries (Was: Re: [HACKERS] Open 7.3 issues)
Actually, I think Jeroen T. Vermeulen [EMAIL PROTECTED] should create the project. It is his code, and if he would add me as an admin, that would help. I am CC'ing him. --- Marc G. Fournier wrote: On Sun, 18 Aug 2002, Peter Eisentraut wrote: Marc G. Fournier writes: Okay, here is what I'd like to suggest ... Bruce, let's start off really simple ... go create a project for libpq++ (I believe someone even volunteered to maintain it?) and let me know once created, and I'll move the CVS directory over for libpq++ and out of the pgsql-server directory I said that I would lend a hand in preparing the build system, but I'm not going to start a project on gborg if I have to agree to a two-page terms of service agreement and I don't get to choose the exact wording of the license. I didn't ask you to, I asked Bruce to ... and the license should stay BSD ... -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: Removing Libraries (Was: Re: [HACKERS] Open 7.3 issues)
Oh, sorry. I will do it now. --- Marc G. Fournier wrote: We're talking about libpq++, not libpqxx :) On Mon, 19 Aug 2002, Bruce Momjian wrote: Actually, I think Jeroen T. Vermeulen [EMAIL PROTECTED] should create the project. It is his code, and if he would add me as an admin, that would help. I am CC'ing him. --- Marc G. Fournier wrote: On Sun, 18 Aug 2002, Peter Eisentraut wrote: Marc G. Fournier writes: Okay, here is what I'd like to suggest ... Bruce, let's start off really simple ... go create a project for libpq++ (I believe someone even volunteered to maintain it?) and let me know once created, and I'll move the CVS directory over for libpq++ and out of the pgsql-server directory I said that I would lend a hand in preparing the build system, but I'm not going to start a project on gborg if I have to agree to a two-page terms of service agreement and I don't get to choose the exact wording of the license. I didn't ask you to, I asked Bruce to ... and the license should stay BSD ... -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(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: Removing Libraries (Was: Re: [HACKERS] Open 7.3 issues)
Done. Called libpq++. --- Bruce Momjian wrote: Oh, sorry. I will do it now. --- Marc G. Fournier wrote: We're talking about libpq++, not libpqxx :) On Mon, 19 Aug 2002, Bruce Momjian wrote: Actually, I think Jeroen T. Vermeulen [EMAIL PROTECTED] should create the project. It is his code, and if he would add me as an admin, that would help. I am CC'ing him. --- Marc G. Fournier wrote: On Sun, 18 Aug 2002, Peter Eisentraut wrote: Marc G. Fournier writes: Okay, here is what I'd like to suggest ... Bruce, let's start off really simple ... go create a project for libpq++ (I believe someone even volunteered to maintain it?) and let me know once created, and I'll move the CVS directory over for libpq++ and out of the pgsql-server directory I said that I would lend a hand in preparing the build system, but I'm not going to start a project on gborg if I have to agree to a two-page terms of service agreement and I don't get to choose the exact wording of the license. I didn't ask you to, I asked Bruce to ... and the license should stay BSD ... -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(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) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(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 issues
On Fri, 16 Aug 2002, Bruce Momjian wrote: Peter Eisentraut wrote: Bruce Momjian writes: Socket permissions - only install user can access db by default unix_socket_permissions in postgresql.conf This is dead. Removed, still on TODO. Daft question but isn't this an administrator's issue? Forcing a complete override of umask isn't usually considered a decent, friendly thing to do and the sys admin can change the permission bits. Besides, what was the proposed scheme? user/group writable world not I presume. I wouldn't even know how to port that to un unixy systems like Win32. -- Nigel J. Andrews Director --- Logictree Systems Limited Computer Consultants ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Open 7.3 issues
Nigel J. Andrews [EMAIL PROTECTED] writes: Daft question but isn't this an administrator's issue? The feature wasn't going to change; the argument was just about whether to change the factory-default permissions mask for the socket. An admin could override the default in any case (and probably should, in many cases). The argument for 0700 was that it is secure, the argument against was that it's useless. No one sane runs their apps as the postgres user, therefore you'd always be having to open it up anyway. We thought a little about 0770 but the problem is that the actual behavior is extremely context-dependent. On some Unixes this is just what you want, on others it's little different from 0777. In any case depending on group membership to control database access means that the DBA *must* have root privileges, which is not an assumption we like to make. So unless someone comes up with a new idea, we're sticking with 0777 for backwards-compatibility reasons. But certainly socket permissions ought to be on the short list of things to think about during every database install. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: Removing Libraries (Was: Re: [HACKERS] Open 7.3 issues)
Marc G. Fournier writes: Okay, here is what I'd like to suggest ... Bruce, let's start off really simple ... go create a project for libpq++ (I believe someone even volunteered to maintain it?) and let me know once created, and I'll move the CVS directory over for libpq++ and out of the pgsql-server directory I said that I would lend a hand in preparing the build system, but I'm not going to start a project on gborg if I have to agree to a two-page terms of service agreement and I don't get to choose the exact wording of the license. I would prefer it if libpq++ would stay in the cvs tree at cvs.postgresql.org. There's no point in starting an entirely new infrastructure elsewhere. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: Removing Libraries (Was: Re: [HACKERS] Open 7.3 issues)
On Sun, 18 Aug 2002, Peter Eisentraut wrote: Marc G. Fournier writes: Okay, here is what I'd like to suggest ... Bruce, let's start off really simple ... go create a project for libpq++ (I believe someone even volunteered to maintain it?) and let me know once created, and I'll move the CVS directory over for libpq++ and out of the pgsql-server directory I said that I would lend a hand in preparing the build system, but I'm not going to start a project on gborg if I have to agree to a two-page terms of service agreement and I don't get to choose the exact wording of the license. I didn't ask you to, I asked Bruce to ... and the license should stay BSD ... ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Removing Libraries (Was: Re: [HACKERS] Open 7.3 issues)
On Thu, 15 Aug 2002, Peter Eisentraut wrote: integrate or remove new libpqxx integrate or add to gborg Pg:DBD Seems like gborg is the place for these. I would volunteer to package libpq++ separately. Okay, the procedure is simple, but where do we want to put this? Do we want to move the extracted libraries over to gborg (would be my first preference), or keep them in the core repository? Regardless of which, the extraction is simple ... but if GBorg, if you go over and make a project and let me know what it is, I can move the library from our CVS repository straight over there, so that we lose no logs or anything ... just let me know its created ... Bruce, can you make a project for Pg::DBD? ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: Removing Libraries (Was: Re: [HACKERS] Open 7.3 issues)
Marc G. Fournier wrote: On Thu, 15 Aug 2002, Peter Eisentraut wrote: integrate or remove new libpqxx integrate or add to gborg Pg:DBD Seems like gborg is the place for these. I would volunteer to package libpq++ separately. Okay, the procedure is simple, but where do we want to put this? Do we want to move the extracted libraries over to gborg (would be my first preference), or keep them in the core repository? Regardless of which, the extraction is simple ... but if GBorg, if you go over and make a project and let me know what it is, I can move the library from our CVS repository straight over there, so that we lose no logs or anything ... just let me know its created ... Bruce, can you make a project for Pg::DBD? OK, I am ready to do the work, but I would like to get a plan of where we are going. I see in interfaces: cli ecpg jdbc libpgeasy libpgtcl libpq libpq++ libpqxx odbc perl5 python and we have Pg:DBD waiting to be added. Now, I know one of Marc's goals is to have libpq as a stand-alone tarball, but I thought we decided that this _didn't_ require it to be in a separate CVS repository. If we split these up based on activity, we have, in decreasing activity order: jdbc odbc libpq libpqxx cli ecpg libpq++ libpgtcl python libpgeasy Pg:DBD perl5 We already have separate web sites for jdbc and odbc, and they are in our main CVS. What goals do we have? Do we create gborg accounts for all/most of these so releases can be made independently of the main server? Do we move their CVS out of the main tree too? I don't think we should judge libpqxx differently than the other interfaces just because it is new. We should find a consistent solution and apply that to all of these interfaces. Let me add that odbc and jdbc have successfully made releases independent of our server for over a year now. I wonder if the best solution is to create gborg accounts for every interface and keep them in our main CVS, and do independent releases from there. Should we point to jdbc/odbc.postgresql.org from gborg? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: Removing Libraries (Was: Re: [HACKERS] Open 7.3 issues)
Bruce Momjian [EMAIL PROTECTED] writes: Now, I know one of Marc's goals is to have libpq as a stand-alone tarball, but I thought we decided that this _didn't_ require it to be in a separate CVS repository. Removing libpq is impossible since psql, pg_dump, etc all depend on it. I don't think we should judge libpqxx differently than the other interfaces just because it is new. The fact that it is new is a strike against it, and the fact that it is not integrated is a bigger strike against it. I think we should move out libpqxx and libpq++ now, and also perl5 if we are going to put DBD::Pg on gborg rather than in the main distro. We want to ensure there is a level playing field for libpqxx and DBD::Pg. jdbc and odbc should be moved if and only if their maintainers want it. I'm not in a hurry to move the rest; they're small and don't generate a lot of CVS traffic. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: Removing Libraries (Was: Re: [HACKERS] Open 7.3 issues)
Marc G. Fournier [EMAIL PROTECTED] writes: Bruce, can you make a project for Pg::DBD? Erm, has anyone contacted the maintainer of DBD::Pg? Given that Bruce doesn't maintain it and AFAIK Jeffrey Baker (the current maintainer) and hasn't expressed any dissatisfaction with CPAN, I'm not sure why you'd like to move the software to GBorg... 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: Removing Libraries (Was: Re: [HACKERS] Open 7.3 issues)
Neil Conway wrote: Marc G. Fournier [EMAIL PROTECTED] writes: Bruce, can you make a project for Pg::DBD? Erm, has anyone contacted the maintainer of DBD::Pg? Given that Bruce doesn't maintain it and AFAIK Jeffrey Baker (the current maintainer) and hasn't expressed any dissatisfaction with CPAN, I'm not sure why you'd like to move the software to GBorg... Uh, I got OK from Edmund. I haven't talked to Jeffrey but I thought someone else had. I thought he had just taken it over and was OK with us handling it. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: Removing Libraries (Was: Re: [HACKERS] Open 7.3 issues)
On Sat, 17 Aug 2002, Bruce Momjian wrote: OK, I am ready to do the work, but I would like to get a plan of where we are going. I see in interfaces: cli ecpg jdbc libpgeasy libpgtcl libpq libpq++ libpqxx odbc perl5 python and we have Pg:DBD waiting to be added. Now, I know one of Marc's goals is to have libpq as a stand-alone tarball, but I thought we decided that this _didn't_ require it to be in a separate CVS repository. Ya, this one I had no problem with ... the only thing with libpq that I do request is that it has its own configure so that it can be completely standalone ... but, IMHO, if someone compiles the server, they are going to need libpq, I just want to make sure taht if they want libpq, they don't need the server ... If we split these up based on activity, we have, in decreasing activity order: jdbc odbc libpq libpqxx cli ecpg libpq++ libpgtcl python libpgeasy Pg:DBD perl5 We already have separate web sites for jdbc and odbc, and they are in our main CVS. What goals do we have? Do we create gborg accounts for all/most of these so releases can be made independently of the main server? Do we move their CVS out of the main tree too? IMHO, yes ... Let me add that odbc and jdbc have successfully made releases independent of our server for over a year now. Correct, so they should be the easiest to move out as well ... I wonder if the best solution is to create gborg accounts for every interface and keep them in our main CVS, and do independent releases from there. Should we point to jdbc/odbc.postgresql.org from gborg? Chris has made code changes to GBorg to allow for this based on requests from Dave Page (ie. PgAdminII) ... so there is no problems with that ... As for keeping them in our main CVS, the more we put over onto GBorg, the more it will get used, test, debugged, pounded and stabilized ... hell, maybe some of the 'dead projects' that are on GBorg will come alive again also if ppl are going to GBorg and find them, download them and hit the authors for fixes :) But, moving the interfaces over will at least give ppl a reason to go over and see what is there ... ---(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: Removing Libraries (Was: Re: [HACKERS] Open 7.3 issues)
On Sat, 17 Aug 2002, Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Now, I know one of Marc's goals is to have libpq as a stand-alone tarball, but I thought we decided that this _didn't_ require it to be in a separate CVS repository. Removing libpq is impossible since psql, pg_dump, etc all depend on it. I don't think we should judge libpqxx differently than the other interfaces just because it is new. The fact that it is new is a strike against it, and the fact that it is not integrated is a bigger strike against it. I think we should move out libpqxx and libpq++ now, and also perl5 if we are going to put DBD::Pg on gborg rather than in the main distro. We want to ensure there is a level playing field for libpqxx and DBD::Pg. jdbc and odbc should be moved if and only if their maintainers want it. I'm not in a hurry to move the rest; they're small and don't generate a lot of CVS traffic. Note: I'm happy enough seeing ppl starting to consider moving this stuff over to GBorg, I, by no means, expect everything to go overnight, or even before v7.3 ... As I mentioned in another message, I'm also kinda hoping that if we start to divert traffic to GBorg for stuff like this, then some of the other projects might 'come alive' again as well ... ---(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: Removing Libraries (Was: Re: [HACKERS] Open 7.3 issues)
Marc G. Fournier wrote: Chris has made code changes to GBorg to allow for this based on requests from Dave Page (ie. PgAdminII) ... so there is no problems with that ... As for keeping them in our main CVS, the more we put over onto GBorg, the more it will get used, test, debugged, pounded and stabilized ... hell, maybe some of the 'dead projects' that are on GBorg will come alive again also if ppl are going to GBorg and find them, download them and hit the authors for fixes :) But, moving the interfaces over will at least give ppl a reason to go over and see what is there ... OK, so create gborg projects for all interfaces, and allow them to release independently. I think we have agreement on that. It can only be a win. That also gives us a mailing list and bug tracking for each interface, which is nice. I think the only unknown is whether their CVS's should be moved out of the main tree. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: Removing Libraries (Was: Re: [HACKERS] Open 7.3 issues)
On Sat, 17 Aug 2002, Bruce Momjian wrote: Marc G. Fournier wrote: Chris has made code changes to GBorg to allow for this based on requests from Dave Page (ie. PgAdminII) ... so there is no problems with that ... As for keeping them in our main CVS, the more we put over onto GBorg, the more it will get used, test, debugged, pounded and stabilized ... hell, maybe some of the 'dead projects' that are on GBorg will come alive again also if ppl are going to GBorg and find them, download them and hit the authors for fixes :) But, moving the interfaces over will at least give ppl a reason to go over and see what is there ... OK, so create gborg projects for all interfaces, and allow them to release independently. I think we have agreement on that. It can only be a win. That also gives us a mailing list and bug tracking for each interface, which is nice. I think the only unknown is whether their CVS's should be moved out of the main tree. Yes, they should be ... maintaining sources in two places would be 'nightmarish' *and* at least GBorg will give a maintainer the ability to add other developers to have CVS access as well, or transferrign maintainership over to someone else ... GBorg is setup so that each project has its own CVSROOT, and its own access controls ... ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: Removing Libraries (Was: Re: [HACKERS] Open 7.3 issues)
Marc G. Fournier [EMAIL PROTECTED] writes: I think the only unknown is whether their CVS's should be moved out of the main tree. Yes, they should be ... Certainly. I was a bit worried about losing CVS history, but Marc indicated he could make the move with history and all, so there's no downside. 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: Removing Libraries (Was: Re: [HACKERS] Open 7.3 issues)
On Sat, 17 Aug 2002, Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] writes: I think the only unknown is whether their CVS's should be moved out of the main tree. Yes, they should be ... Certainly. I was a bit worried about losing CVS history, but Marc indicated he could make the move with history and all, so there's no downside. Okay, here is what I'd like to suggest ... Bruce, let's start off really simple ... go create a project for libpq++ (I believe someone even volunteered to maintain it?) and let me know once created, and I'll move the CVS directory over for libpq++ and out of the pgsql-server directory ... ---(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 issues
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: What does -f do? There is concern that using pg_resetxlog by accident could cause problems, so it will prompt the user for confirmation by default. -f (force) disables that confirmation. pg_resetxlog already has an -f switch, and I do not think you should change its semantics. At least not without putting up a better argument than the above. Anyone who's running pg_resetxlog had already better know what they're doing. I hadn't looked at flags yet. Thomas's concern, and I think a valid one, is that if we move it from contrib into the main tree, people may accidentally run pg_resetxlog without understanding the issues involved. We have it /contrib partly to make sure it isn't installed in the default path for all admins. What do people want? We can rethink this. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(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 issues
Bruce Momjian [EMAIL PROTECTED] writes: I hadn't looked at flags yet. Thomas's concern, and I think a valid one, is that if we move it from contrib into the main tree, people may accidentally run pg_resetxlog without understanding the issues involved. There's already an interlock to prevent you from running it against a live installation (it won't run if it sees a postmaster lock file). That should also prevent an accidental run against a crashed installation (presumably a lockfile will still be there). And if you run it against a cleanly-shut-down installation, it's harmless because you don't need the old xlog. I don't think we need to be so paranoid as to insist that you say pg_resetxlog --yes-i-read-the-manual before it will do anything. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Open 7.3 issues
OK, sounds reasonable. --- Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I hadn't looked at flags yet. Thomas's concern, and I think a valid one, is that if we move it from contrib into the main tree, people may accidentally run pg_resetxlog without understanding the issues involved. There's already an interlock to prevent you from running it against a live installation (it won't run if it sees a postmaster lock file). That should also prevent an accidental run against a crashed installation (presumably a lockfile will still be there). And if you run it against a cleanly-shut-down installation, it's harmless because you don't need the old xlog. I don't think we need to be so paranoid as to insist that you say pg_resetxlog --yes-i-read-the-manual before it will do anything. regards, tom lane -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Open 7.3 issues
Bruce Momjian wrote: Jan Wieck wrote: Bruce Momjian wrote: Allow PL/PgSQL functions to return sets Is anyone working on this? We will get beaten up if we don't have this for 7.3 and it is available in other languages. That's true. I think I have to do this one. I'm busy for the next 2-3 weeks (Mom will be back from her Westcoast trip tonight and stay for another 3 weeks). But I should be able to do something after that. Nope. We are in beta then. Either someone else will have to do it or it will wait for 7.4. Since PL/pgSQL is a loadable module still, we might be able to provide an upgrade after 7.3 is out instead of waiting for 7.4. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Open 7.3 issues
Jan Wieck [EMAIL PROTECTED] writes: Since PL/pgSQL is a loadable module still, we might be able to provide an upgrade after 7.3 is out instead of waiting for 7.4. Maybe, but you'd have to get the core-code end of it in before beta. AFAIR Joe's patch doesn't yet cover any return style from a function except one-row-at-a-time. 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] Open 7.3 issues
Tom Lane wrote: Jan Wieck [EMAIL PROTECTED] writes: Since PL/pgSQL is a loadable module still, we might be able to provide an upgrade after 7.3 is out instead of waiting for 7.4. Maybe, but you'd have to get the core-code end of it in before beta. AFAIR Joe's patch doesn't yet cover any return style from a function except one-row-at-a-time. Neil said he was working on this and expected to have it done for 7.3. I think he's using the approach we discussed at OSCON, namely generating a tuplestore within the plpgsql module and passing it back to FunctionNext. Joe ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Open 7.3 issues
Joe Conway wrote: Tom Lane wrote: Jan Wieck [EMAIL PROTECTED] writes: Since PL/pgSQL is a loadable module still, we might be able to provide an upgrade after 7.3 is out instead of waiting for 7.4. Maybe, but you'd have to get the core-code end of it in before beta. AFAIR Joe's patch doesn't yet cover any return style from a function except one-row-at-a-time. Neil said he was working on this and expected to have it done for 7.3. I think he's using the approach we discussed at OSCON, namely generating a tuplestore within the plpgsql module and passing it back to FunctionNext. If I understand correctly, it is a great idea because it uses the cursor return support already in pl/pgsql to handle it. Great idea. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(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 issues
Christopher Kings-Lynne wrote: [ ... ] What about this. 1. Implement pg_get_foreignkey_def() or whatever 2. Adjust pg_dump to dump foreign keys using an ALTER statement 3. Back port the above to rel 7_2_2 4. Release a 7.2.2 version and ask that people upgrade to that version and do a dump before they upgrade to 7.3. 5. All is well, plus ppl who don't want to switch to 7.3 on production get all sorts of useful bug fixes as well. If we have to have a 7.2.2 release, I'd like to suggest to backport create or replace view , it it doesn't use any 7.3-specific feature. This one is my pet peeve at the moment ... ;-) Would give a *lot* of end-user functionality (and I am a and-user, after all), at little cost, if I'm not mistaken ...). -- Emmanuel Charpeentier ---(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 issues
On Thu, Aug 15, 2002 at 12:09:00AM -0400, Neil Conway wrote: Bruce Momjian [EMAIL PROTECTED] writes: ... integrate or remove new libpqxx integrate or add to gborg Pg:DBD Seems like gborg is the place for these. Yes, but I'd also like to see libpq++, perl5, and possibly some other interfaces re-packaged separately. I think everyone agrees on the direction here, it just needs someone (Marc?) to do the work. Would the method of use be - checkout postgresql - cd pgsql/src/interfaces - checkout libpq++ from gborg - cd ../.. - configure --with-CXX or would libpq++ become more removed.. (configure options to libpq++ to point to the rest or pgsql?) Cheers, Patrick (prefer former) ---(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 issues
On Thursday 15 August 2002 12:28 am, Tom Lane wrote: I think that's likely to be a hard sell. The most we are likely to get is to ask people to use the 7.3 pg_dump to dump their 7.2 server when they are about to upgrade to 7.3 --- even that much is a difficult trick for RPM users. It's more of a difficult trick for the RPM maintainer :-) No, I've thought about this possibility, and I can see packaging a 'postgresql-pg_dump73-7.2.1' RPM consisting entirely of the 7.3 pg_dump linked against the pieces of 7.2.1 necessary. Ugly, but doable. I know I sound like a broken record (for those who remember vinyl records), but good upgrading tools would eliminate this recurring problem. That's all I'm saying about that this time -- I've said enough, and it's all archived for those who care to know what I think about the state of upgrading. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Open 7.3 issues
Actually, my _big_ question is whether the lack of dependency info coming from 7.2 is going to cause problems in 7.3, i.e. do we make assumptions that dependency info is there and in cases it isn't, are there surprises for users, where things worked fine in 7.2. I want to know if there are cases where we assumed dependency info was there when in 7.2 we handled the lack of depenency better. --- Tom Lane wrote: Christopher Kings-Lynne [EMAIL PROTECTED] writes: What about this. 1. Implement pg_get_foreignkey_def() or whatever 2. Adjust pg_dump to dump foreign keys using an ALTER statement 3. Back port the above to rel 7_2_2 4. Release a 7.2.2 version and ask that people upgrade to that version and do a dump before they upgrade to 7.3. The trouble with this is that 7.2.2 would include a lot of rather poorly tested code (code that has not even made it to CVS yet) ... and if there's a problem in that code, it breaks dump files whether you are an early upgrader to 7.3 or not. I think that's likely to be a hard sell. The most we are likely to get is to ask people to use the 7.3 pg_dump to dump their 7.2 server when they are about to upgrade to 7.3 --- even that much is a difficult trick for RPM users. The other problem is that given a 7.2 system catalog setup, it's not really any easier to reconstruct this is a foreign key on the server side than it is to do it on the pg_dump side. So if we can figure out how to do it at all, we might as well make pg_dump do the work instead of insisting on a server update. regards, tom lane -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(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 issues
Bruce Momjian [EMAIL PROTECTED] writes: coming from 7.2 is going to cause problems in 7.3, i.e. do we make assumptions that dependency info is there and in cases it isn't, are there surprises for users, where things worked fine in 7.2. I want to know if there are cases where we assumed dependency info was there when in 7.2 we handled the lack of depenency better. No, we have not broken any cases that used to work, AFAIK. There are new features in 7.3 that will not work in a database made from a 7.2 dump --- for example, dropping an old table containing a serial column won't make the sequence go away, because we won't have a dependency link between the table and the sequence. But it didn't go away in 7.2 either, so the behavior's no worse. Another thing we won't understand is that certain sets of triggers make up a foreign-key constraint, so you won't be able to use ALTER TABLE DROP CONSTRAINT to delete 'em. But you couldn't in 7.2 either. While I've toyed with the notion of trying to intuit these dependencies as we reload a database, I'm not at all sure it's a good idea. The former 7.2 user might be quite unhappy if we drop a sequence he wasn't expecting to have dropped. We cannot tell for certain how the sequence was made --- it might have been handmade and then used in an explicit DEFAULT expression, in which case an auto-drop dependency would probably not be a friendly thing to spring on the user. The bulk of the new dependencies are made automatically as we handle CREATE statements, so they'll be correct in a reloaded database anyway. AFAIR it's just serial sequences and foreign keys that are not going to be as bright as they might be. 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] Open 7.3 issues
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: coming from 7.2 is going to cause problems in 7.3, i.e. do we make assumptions that dependency info is there and in cases it isn't, are there surprises for users, where things worked fine in 7.2. I want to know if there are cases where we assumed dependency info was there when in 7.2 we handled the lack of depenency better. No, we have not broken any cases that used to work, AFAIK. There are new features in 7.3 that will not work in a database made from a 7.2 dump --- for example, dropping an old table containing a serial column won't make the sequence go away, because we won't have a dependency link between the table and the sequence. But it didn't go away in 7.2 either, so the behavior's no worse. Another thing we won't understand is that certain sets of triggers make up a foreign-key constraint, so you won't be able to use ALTER TABLE DROP CONSTRAINT to delete 'em. But you couldn't in 7.2 either. While I've toyed with the notion of trying to intuit these dependencies as we reload a database, I'm not at all sure it's a good idea. The former 7.2 user might be quite unhappy if we drop a sequence he wasn't expecting to have dropped. We cannot tell for certain how the sequence was made --- it might have been handmade and then used in an explicit DEFAULT expression, in which case an auto-drop dependency would probably not be a friendly thing to spring on the user. The bulk of the new dependencies are made automatically as we handle CREATE statements, so they'll be correct in a reloaded database anyway. AFAIR it's just serial sequences and foreign keys that are not going to be as bright as they might be. OK, that's what I needed to know. It may be confusing to some users that 7.2 serial/foreign keys don't auto-drop while 7.3 do. We need to mention that in the release notes. I think that will be enough, but I can imagine people dumping/reloading their db's to get that dependency, and I am not sure how we would tell them to do that. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Open 7.3 issues
Bruce Momjian writes: Socket permissions - only install user can access db by default unix_socket_permissions in postgresql.conf This is dead. glibc and mktime() - fix? Leave it be. If someone really needs time information from before 1970 (and who does?) he wouldn't use an OS that doesn't support it anyway. There are several platforms that don't have complete time information before 1947 and we've lived with those, too. ecpg and bison issues - solved? A release is cooking. 1.49b was released just a few days ago. Assuming that it is sane and no final release comes out before beta, we might ship our beta built with their beta and coordinate with them to make a final release during our beta. It's a bit risky, but the more testing we can provide to them the faster they will get a release out. fix BeOS and QNX4 ports Should we ship 7.3 without these ports? Porters usually appear during beta. integrate or remove new libpqxx integrate or add to gborg Pg:DBD Seems like gborg is the place for these. I would volunteer to package libpq++ separately. move pg_resetxlog and pg_controldata to main tree, add -f flag That is me. I will get to it. What does -f do? -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Open 7.3 issues
Jan Wieck wrote: Bruce Momjian wrote: Allow PL/PgSQL functions to return sets Is anyone working on this? We will get beaten up if we don't have this for 7.3 and it is available in other languages. That's true. I think I have to do this one. I'm busy for the next 2-3 weeks (Mom will be back from her Westcoast trip tonight and stay for another 3 weeks). But I should be able to do something after that. Nope. We are in beta then. Either someone else will have to do it or it will wait for 7.4. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Open 7.3 issues
OK, I removed this 7.3 open item and added a documentation item for the release notes: Mention foreign keys and SERIAL dependencies will not be in 7.2 loaded tables --- Rod Taylor wrote: Dependency - have pg_dump auto-create dependencies when loading 7.2.X data? Are we as far as we can go here? The only trouble maker is foreign keys. If there was a nice way of finding foreign keys in 7.2 and prior it probably would have been implemented a long time ago in pg_dump :) Something in the release notes about how the foreign key dependency stuff only works if they drop all current foreign keys (drop trigger) and re-add them via alter table add foreign key is suggested. Worst case scenario for Foreign keys is they will have what they always had. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(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 issues
Neil Conway wrote: Bruce Momjian [EMAIL PROTECTED] writes: remove interfaces/ssl if not improved I am ready to yank this. Agreed. Done and item removed. allow specification of configuration files in a different directory? Anyone working on this? Not sure we need this for 7.3 -- unless (a) someone steps up to do the work (b) there is some consensus on the design, I don't have a problem with letting this wait for 7.4 Removed. No one has jumped on this. Added to TODO: * Allow configuration files to be specified in a different directory Allow PL/PgSQL functions to return sets Is anyone working on this? I am. It should be ready in time for 7.3. OK. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Open 7.3 issues
Joe Conway wrote: Fix bytea to not encode input string Not sure we can do these. As I said, it isn't clear to me how this can be fixed without a fe/be protocol change. But if someone can point me in the direction of a viable fix for 7.3, I'll dive in. OK, item removed and added to TODO: * Prevent mismatch of frontend/backend encodings from converting bytea data from being interpreted as encoded strings -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Open 7.3 issues
Tom Lane wrote: I'm concerned, but in the few moments I've had to play with this, what looked like the obvious fix didn't seem to work (I was hacking on glibc itself though). Red Hat's internal opinion seems to be that #define NO_MKTIME_BEFORE_1970 is a sufficient answer. I consider that well to the south of sucking, but at this point I really doubt that we have the time to implement a better answer for 7.3. A better answer seems to mean writing our own interface to the zic timezone database. Make no mistake: I think we should do that, and will do it eventually. I just doubt it'll happen in the next two weeks. And again, I do not feel we should hold up 7.3 to wait for a solution. So everyone's conclusion is that we can't patch over this problem with a patched up version on the link line, so I will just add it to the TODO list: * Fix glibc's mktime() to handle pre-1970's dates Do we have a way to detect this bug and warn users somehow? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Open 7.3 issues
Peter Eisentraut wrote: Bruce Momjian writes: Socket permissions - only install user can access db by default unix_socket_permissions in postgresql.conf This is dead. Removed, still on TODO. glibc and mktime() - fix? Leave it be. If someone really needs time information from before 1970 (and who does?) he wouldn't use an OS that doesn't support it anyway. There are several platforms that don't have complete time information before 1947 and we've lived with those, too. Removed. Added to TODO. ecpg and bison issues - solved? A release is cooking. 1.49b was released just a few days ago. Assuming that it is sane and no final release comes out before beta, we might ship our beta built with their beta and coordinate with them to make a final release during our beta. It's a bit risky, but the more testing we can provide to them the faster they will get a release out. We will see... fix BeOS and QNX4 ports Should we ship 7.3 without these ports? Porters usually appear during beta. Well, we don't really want porting fixes during beta unless we can help it. ;-) integrate or remove new libpqxx integrate or add to gborg Pg:DBD Seems like gborg is the place for these. I would volunteer to package libpq++ separately. move pg_resetxlog and pg_controldata to main tree, add -f flag That is me. I will get to it. What does -f do? There is concern that using pg_resetxlog by accident could cause problems, so it will prompt the user for confirmation by default. -f (force) disables that confirmation. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(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 issues
Bruce Momjian [EMAIL PROTECTED] writes: What does -f do? There is concern that using pg_resetxlog by accident could cause problems, so it will prompt the user for confirmation by default. -f (force) disables that confirmation. pg_resetxlog already has an -f switch, and I do not think you should change its semantics. At least not without putting up a better argument than the above. Anyone who's running pg_resetxlog had already better know what they're doing. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Open 7.3 issues
Here are some comments on the open 7.3 items. We have to start pairing this down if we are going to hit beta in 2.5 weeks: --- P O S T G R E S Q L 7 . 3 O P E NI T E M S Current at ftp://candle.pha.pa.us/pub/postgresql/open_items. Source Code Changes --- Socket permissions - only install user can access db by default unix_socket_permissions in postgresql.conf Are we going to do anything with sockets permissions to tighten things up? I know of one big client where PostgreSQL got a bad rap for being open to all local users by default. Point-in-time recovery - ready for 7.3? This seems very unlikely now. Status? Allow easy display of usernames in a group (pg_hba.conf uses groups now) I was hoping for something on this because we are now using groups for pg_hba.conf. If not, we can add it to TODO. I think it is already there. Reindex/btree shrinkage - does reindex need work, can btree be shrunk? Can we do anything here? display locks - ready? This one is waiting to be applied. Win32 - timefame? Seems like a non-issue for 7.3. Prepared statements - ready? New version submitted recently. Is it ready to be applied? Schema handling - ready? interfaces? client apps? We need a posting describing what interfaces/applictions need to look at for schemas. Dependency - have pg_dump auto-create dependencies when loading 7.2.X data? Are we as far as we can go here? glibc and mktime() - fix? I can do the work on this I need more info and no one seems to be conerned. ecpg and bison issues - solved? Do we have a fallback position on this if bison can't get a fixed version? improve macros in new tuple header code have pg_dumpall dump out db privilege and per-user/db settings These need to be done. fix BeOS and QNX4 ports Should we ship 7.3 without these ports? fix implicit type coercions that are worse Details? remove interfaces/ssl if not improved I am ready to yank this. integrate or remove new libpqxx integrate or add to gborg Pg:DBD Seems like gborg is the place for these. allow specification of configuration files in a different directory? Anyone working on this? handle lack of secondary passwords? We are discussing this so I think we can get this done soon. move pg_resetxlog and pg_controldata to main tree, add -f flag That is me. I will get to it. Allow PL/PgSQL functions to return sets Is anyone working on this? We will get beaten up if we don't have this for 7.3 and it is available in other languages. Fix bytea to not encode input string Fix db, function, language permissions on 7.2 database loads Not sure we can do these. Agree on PGXLOG/-X handling This is still an open item. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Open 7.3 issues
Dependency - have pg_dump auto-create dependencies when loading 7.2.X data? Are we as far as we can go here? The only trouble maker is foreign keys. If there was a nice way of finding foreign keys in 7.2 and prior it probably would have been implemented a long time ago in pg_dump :) Something in the release notes about how the foreign key dependency stuff only works if they drop all current foreign keys (drop trigger) and re-add them via alter table add foreign key is suggested. Worst case scenario for Foreign keys is they will have what they always had. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Open 7.3 issues
Dependency - have pg_dump auto-create dependencies when loading 7.2.X data? Are we as far as we can go here? The only trouble maker is foreign keys. If there was a nice way of finding foreign keys in 7.2 and prior it probably would have been implemented a long time ago in pg_dump :) What about this. 1. Implement pg_get_foreignkey_def() or whatever 2. Adjust pg_dump to dump foreign keys using an ALTER statement 3. Back port the above to rel 7_2_2 4. Release a 7.2.2 version and ask that people upgrade to that version and do a dump before they upgrade to 7.3. 5. All is well, plus ppl who don't want to switch to 7.3 on production get all sorts of useful bug fixes as well. Chris ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Open 7.3 issues
Bruce Momjian [EMAIL PROTECTED] writes: remove interfaces/ssl if not improved I am ready to yank this. Agreed. integrate or remove new libpqxx integrate or add to gborg Pg:DBD Seems like gborg is the place for these. Yes, but I'd also like to see libpq++, perl5, and possibly some other interfaces re-packaged separately. I think everyone agrees on the direction here, it just needs someone (Marc?) to do the work. allow specification of configuration files in a different directory? Anyone working on this? Not sure we need this for 7.3 -- unless (a) someone steps up to do the work (b) there is some consensus on the design, I don't have a problem with letting this wait for 7.4 Allow PL/PgSQL functions to return sets Is anyone working on this? I am. It should be ready in time for 7.3. 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 issues
On Thu, 2002-08-15 at 00:01, Christopher Kings-Lynne wrote: Dependency - have pg_dump auto-create dependencies when loading 7.2.X data? Are we as far as we can go here? The only trouble maker is foreign keys. If there was a nice way of finding foreign keys in 7.2 and prior it probably would have been implemented a long time ago in pg_dump :) What about this. 1. Implement pg_get_foreignkey_def() or whatever I've done the parsing of foreign key triggers required in the past for various documentation purposes and it wasn't overly fun -- nor am I sure it's right in all cases. Find 3 triggers with is_constraint true between two tables that match argument sets, split argument list by comma, first 4 aren't so useful, the rest in pairs are source / destination columns. Foreign Key state (deferred, match, etc.) is in the function naming convention. If you want to give it a shot, feel free. Whatever method is in place will need to work on 7.3 for those who didn't use a newer pg_dump on the older database. ---(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 issues
Christopher Kings-Lynne [EMAIL PROTECTED] writes: What about this. 1. Implement pg_get_foreignkey_def() or whatever 2. Adjust pg_dump to dump foreign keys using an ALTER statement 3. Back port the above to rel 7_2_2 4. Release a 7.2.2 version and ask that people upgrade to that version and do a dump before they upgrade to 7.3. The trouble with this is that 7.2.2 would include a lot of rather poorly tested code (code that has not even made it to CVS yet) ... and if there's a problem in that code, it breaks dump files whether you are an early upgrader to 7.3 or not. I think that's likely to be a hard sell. The most we are likely to get is to ask people to use the 7.3 pg_dump to dump their 7.2 server when they are about to upgrade to 7.3 --- even that much is a difficult trick for RPM users. The other problem is that given a 7.2 system catalog setup, it's not really any easier to reconstruct this is a foreign key on the server side than it is to do it on the pg_dump side. So if we can figure out how to do it at all, we might as well make pg_dump do the work instead of insisting on a server update. 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] Open 7.3 issues
Bruce Momjian wrote: Point-in-time recovery - ready for 7.3? This seems very unlikely now. Status? It would be a shame to have to wait for 7.4 for this one. glibc and mktime() - fix? I can do the work on this I need more info and no one seems to be conerned. I'm concerned, but in the few moments I've had to play with this, what looked like the obvious fix didn't seem to work (I was hacking on glibc itself though). Allow PL/PgSQL functions to return sets Is anyone working on this? We will get beaten up if we don't have this for 7.3 and it is available in other languages. I saw Neil's response. I'll jump in to help if he needs any. Fix bytea to not encode input string Not sure we can do these. As I said, it isn't clear to me how this can be fixed without a fe/be protocol change. But if someone can point me in the direction of a viable fix for 7.3, I'll dive in. Joe ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Open 7.3 issues
Joe Conway [EMAIL PROTECTED] writes: Bruce Momjian wrote: Point-in-time recovery - ready for 7.3? This seems very unlikely now. Status? It would be a shame to have to wait for 7.4 for this one. If a credible patch appears before the end of the month, great --- but the discussions so far have left me feeling that we're still a ways away from PITR. And I *don't* want to hold up 7.3 to wait for it. Learned that lesson with WAL for 7.1 ... glibc and mktime() - fix? I can do the work on this I need more info and no one seems to be conerned. I'm concerned, but in the few moments I've had to play with this, what looked like the obvious fix didn't seem to work (I was hacking on glibc itself though). Red Hat's internal opinion seems to be that #define NO_MKTIME_BEFORE_1970 is a sufficient answer. I consider that well to the south of sucking, but at this point I really doubt that we have the time to implement a better answer for 7.3. A better answer seems to mean writing our own interface to the zic timezone database. Make no mistake: I think we should do that, and will do it eventually. I just doubt it'll happen in the next two weeks. And again, I do not feel we should hold up 7.3 to wait for a solution. 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])
