Thread: Schedule for 8.1 feature freeze
We have addressed all the open issues for 8.1 except for auto-vacuum, which Alvaro is working on, so I think we are ready for a feature freeze on July 1. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
> -----Original Message----- > From: pgsql-hackers-owner@postgresql.org > [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Bruce Momjian > Sent: 21 June 2005 05:04 > To: PostgreSQL-development > Subject: [HACKERS] Schedule for 8.1 feature freeze > > We have addressed all the open issues for 8.1 except for auto-vacuum, > which Alvaro is working on, so I think we are ready for a > feature freeze > on July 1. What about Andreas' instrumentation stuff? This has been going on since before 8.0 and it would good to get it in 8.1 given the amount of extra functionality it allows us to offer users that prefer a GUI interface. I realise there probably won't be time to fix pg_terminate_backend, or convince people that it offers the admin the lesser of two evils (my limited understanding being that there is a chance of it not clearing some locks, vs, having to shut down the whole server to kill a single connection) - can we at least get the other functions applied? Thanks, Dave.
> We have addressed all the open issues for 8.1 except for > auto-vacuum, which Alvaro is working on, so I think we are > ready for a feature freeze on July 1. I don't beleive we have :-( The server instrumentation patch is not yet addressed. Last I checked there was the objections to pg_terminate_backend (which are certainly valid,though I and many other still claim this is in daily use at *a lot* of installations), and nothing substantial to the rest of the patch. yet it hasn't even made it to the queue (the patch would still be very useful with just the parts except pg_terminate_backend). I beleive Andreas is working on separating out the pg_terminate_backend part to a separate patch to make it easier for whomever would apply it. There is also the ICU patch. this is *very* much needed for win32, and from how I read it it's also needed for other platforms. Last I heard Palle planned to have it fixed up before feature freeze (I'm not sure exactly what more needed to be fixed). If not then we have to do something else about unicode on win32 (perhaps under the flag of "bugfix", but I'm sure it will be more invasive than most would like). But I realy think a cross-platform thing like ICU is much better. And there's a pending patch that redoes signal handling on win32. I haven't had the time to check it through myself, as I've been unexpectedly-out-of-town several times lately, but it was posted some time ago and shoudl probalby be at least considered. (I'm not 100% sure it's a worthwhile simplification myself, but I'll have to look into it muc more careful before I can form an actual opinion on it) Finally a heads-up: I'm looking at an updated patch to remove the Kerberos V4 support. I posted to both hackers and general a month ago asking for people who use it for exactly zero responses. It's not quite done yet, but I plan to have it done before July 1st. But it's definitly not something to hold up a freeze date for if I'm not. Is there an "Open Issues" list yet, as you usually prepare for releases? If so, can you please put these items up on it? //Magnus
>> -----Original Message-----
>> From: pgsql-hackers-owner@postgresql.org
>> [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Bruce Momjian
>> Sent: 21 June 2005 05:04
>> To: PostgreSQL-development
>> Subject: [HACKERS] Schedule for 8.1 feature freeze
>>
>> We have addressed all the open issues for 8.1 except for auto-vacuum,
>> which Alvaro is working on, so I think we are ready for a
>> feature freeze
>> on July 1.
Bruce, we're working on GiST concurrency which is based on GiST recovery
code already submitted. Hopefully, we'll submit patch before July 1.
There is also one problem we already discussed - we have no gist opclasses
in core we could use for regression tests ! Probably, it's a time we need
to add some opclasses from intarray or rtree_gist to core ?
btw, there was a noise about funding of our work, but I've contacted only
with PostGis guys about real contribution. I'm just wondered if any
commercial clones do really understand the importance of our work. Should
I write some explanation what're recovery and concurrency for GiST ?
Regards, Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83
* Bruce Momjian (pgman@candle.pha.pa.us) wrote:
> We have addressed all the open issues for 8.1 except for auto-vacuum,
> which Alvaro is working on, so I think we are ready for a feature freeze
> on July 1.
Bruce,
I'd really like to see role support added into 8.1. I've sent Alvaro and Tom versions of the patch in the past and I
wasplanning on submitting it to -patches soon. There's a few remaining issue but I don't think they'll take very long
toclean up; I've just been unfortunately pretty busy lately. I'm hopeful that I'll be able to spend some time on it
thisweek and next week to hopefully address at least the remaining issues on my list.
Lookups need to do multi-level role resolution (for owner and other ACL areas) (Not very hard, and mostly isolated
tothe acl code) Need to implement per-backend role-member cacheing (Not very hard, basically same kind of way
pg_namespacedoes schema_path) Support 'grant <role> to <role>' (Shouldn't be too difficult, mainly just parser
work)Support 'with admin option' (Somewhat difficult, but not necessary for the same functionality we have today)
Support'granted by' (Not very hard, just parser work really) Fix other parsers (ecpg, etc) based on updates to
backend/parser. (Worked on this some already, should be done real soon now) Distinguish 'create role' permissions from
'superuser'? (Not sure if this makes sense)
Modify \du, \dg to use new tables (They work already using the backwards-compat views, just would be nice to
updatethem to the new schema). ? Add \dr, \dm (Should be easy and would be nice I think, though perhaps not
required)
Add documentation for CREATE ROLE/etc Document new system catalogs (pg_authid, pg_auth_members) (Documentation
updates)
There are views for pg_shadow/pg_group and things seem to be happy with them. CREATE USER/CREATE GROUP work
more-or-lessas expected. An interesting side-effect is that if you do 'create group' and then look in the 'group' table
youdon't see the group till you actually put users in it. Not entirely sure if anything actually depends on that (You
can,after all, still grant rights to the role which was created by CREATE GROUP, and do ALTER GROUP on it, etc).
Thanks,
Stephen
> I realise there probably won't be time to fix pg_terminate_backend, or > convince people that it offers the admin the lesser of two evils (my > limited understanding being that there is a chance of it not clearing > some locks, vs, having to shut down the whole server to kill a single > connection) - can we at least get the other functions applied? Not clearing those locks frequently results in a "Lock Table corruption" message and panic at some unknown point in the future, and is probably not something we want to encourage. It looks really bad when it happens hours or days after the connection was killed because the user isn't going to associate those two actions. This is a feature I'm really looking forward too, but it's not ready for general consumption yet. --
Stephen Frost <sfrost@snowman.net> writes:
> I'd really like to see role support added into 8.1. I've sent Alvaro
> and Tom versions of the patch in the past and I was planning on
> submitting it to -patches soon. There's a few remaining issue but I
> don't think they'll take very long to clean up; I've just been
> unfortunately pretty busy lately. I'm hopeful that I'll be able to
> spend some time on it this week and next week to hopefully address at
> least the remaining issues on my list.
Stephen, it is not going to be acceptable to sit on that patch until
June 30 --- there are other things depending on it. If you don't have
time for it now, send in what you have so that someone else can pick up
the ball.
regards, tom lane
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > I'd really like to see role support added into 8.1. I've sent Alvaro
> > and Tom versions of the patch in the past and I was planning on
> > submitting it to -patches soon. There's a few remaining issue but I
> > don't think they'll take very long to clean up; I've just been
> > unfortunately pretty busy lately. I'm hopeful that I'll be able to
> > spend some time on it this week and next week to hopefully address at
> > least the remaining issues on my list.
>
> Stephen, it is not going to be acceptable to sit on that patch until
> June 30 --- there are other things depending on it. If you don't have
> time for it now, send in what you have so that someone else can pick up
> the ball.
Sorry, I thought that's what I had been doing when sending to
you/Alvaro/-hackers earlier.. I'll send in what I've got and I guess
see what happens. I'm planning on still working on it when I have time
available so if someone else picks it up to work on it, please let me
know so we can coordinate.
Thanks,
Stephen
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> We have addressed all the open issues for 8.1 except for auto-vacuum,
Aside from the other stuff people mentioned, I have these things on
my to-look-at list:
* Fix pg_dump to be able to dump large objects in text dumps
* Fix inherited constraints (per discussion around 5/20)
* Fix reporting of table/column numbers for cursors (per DeSoi, 4/9)
* statement_timeout does not behave very reasonably for V3 messages
And I'd really like to see pg_role and shared dependencies get in...
regards, tom lane
Bruce Momjian wrote: >We have addressed all the open issues for 8.1 except for auto-vacuum, >which Alvaro is working on, so I think we are ready for a feature freeze >on July 1. > > > FYI - plperl status. I am trying to get the following 2 items done by feature freeze: . convert returned perl array to pg array (see patch recently sent for discussion) . validator function The remaining memory issue we have is where plperl does a huge select via SPI. Abhijit Menon-Sen was working on this but is stumped on how to proceed (see his previous message). We have a patch from CommandPrompt which apparently improves the situation, although it doesn't solve the basic problem. If we don't make progress with Abhijit's work, I will look at working that up by July 1. There is also the tiny patch to trap lexical warnings I submitted not long ago still outstanding. cheers andrew
I'll do my best to submit bitmap index AM patch next week for your review. -- Victor Y. Yegorov
Dave Page wrote: > > > > -----Original Message----- > > From: pgsql-hackers-owner@postgresql.org > > [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Bruce Momjian > > Sent: 21 June 2005 05:04 > > To: PostgreSQL-development > > Subject: [HACKERS] Schedule for 8.1 feature freeze > > > > We have addressed all the open issues for 8.1 except for auto-vacuum, > > which Alvaro is working on, so I think we are ready for a > > feature freeze > > on July 1. > > What about Andreas' instrumentation stuff? This has been going on since > before 8.0 and it would good to get it in 8.1 given the amount of extra > functionality it allows us to offer users that prefer a GUI interface. > > I realise there probably won't be time to fix pg_terminate_backend, or > convince people that it offers the admin the lesser of two evils (my > limited understanding being that there is a chance of it not clearing > some locks, vs, having to shut down the whole server to kill a single > connection) - can we at least get the other functions applied? [ CC to Andreas.] OK, let me address this, but you might not like what I have to say. ;-) Basically, Andreas' approach for 8.0 was to develop a patch (without posting a proposal or interface), and then argue why pgadmin needs it, but without addressing the real concerns about the patch. Saying pgadmin needs it just isn't enough to get a patch in. There are the issues of security and maintainability that have to be addressed, and in the limited time we had to do this in 8.0, it was clear the patch should not be applied. Now, in 8.1, the same thing has happened. Two weeks before feature freeze, with no discussion, the patch appears, and makes no reference to concerns raised during the 8.0 discussion. pg_terminate_backend is even in the patch, and there is no mention or attempt to address concerns we had in 8.0. The move of dbsize into the backend is similar. He moves the parts of dbsize the pgadmin needs into the backend, but makes no mention or change to /contrib/dbsize to adjust it to the movement of the code. He has since posted and updated version that fixes this, I think, but again, we have to discuss how this is to be done --- do we move all the dbsize functions into the backend, some, or none? Do the other dbsize functions stay in /contrib or get deleted? This needs discussion, not a patch. And because there are so many assumptions made in the patch, the patch committers look unreasonable asking for X changes to his patch, when in fact he made X assumptions in the patch and never asked anyone before developing the patch about those assumptions. Basically, I think this is a great example of how _not_ to do things in the community: o don't post your proposal for discussiono don't mention controversial issues in your patcho don't fully address codemigrations in your patch It seems like the goal is to throw in the patch on the hopes that no one will remember or realize the problems before it gets into CVS. What has to happen now is that we need to restart the server instrumentation discussion with a proposal of what needs to be added to the server, and why, and then we can deal with any concerns raised. The same is true with the dbsize patch. Bad news, yea, but I think it is the only way to move forward. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Andrew Dunstan wrote: > There is also the tiny patch to trap lexical warnings I submitted not > long ago still outstanding. OK, I missed that one. I see it at: http://archives.postgresql.org/pgsql-patches/2005-06/msg00280.php However, I don't see the new regession files attached to that URL. Would you repost please? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Magnus Hagander wrote: > Is there an "Open Issues" list yet, as you usually prepare for releases? > If so, can you please put these items up on it? Yes, it is at: This item has been added to the 7.4 open items list: http://candle.pha.pa.us/cgi-bin/pgopenitems It did contain only pgautovacuum, but has been updated with the new items. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > We have addressed all the open issues for 8.1 except for auto-vacuum, > which Alvaro is working on, so I think we are ready for a feature freeze > on July 1. FWIW, I'm still working on column-level triggers, but the July 1st deadline should not be a problem. - -- Greg Sabino Mullane greg@turnstep.com PGP Key: 0x14964AC8 200506211841 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iD8DBQFCuJe+vJuQZxSWSsgRAkSnAKDhwsRXoupe1DhHGgCYrquimK9CJQCgz1K5 /nHRvPxNs+41vxs7G9ngvW4= =C+M3 -----END PGP SIGNATURE-----
On Jun 21, 2005, at 1:03 PM, Bruce Momjian wrote: > We have addressed all the open issues for 8.1 except for auto-vacuum, > which Alvaro is working on, so I think we are ready for a feature > freeze > on July 1. > > I'm hoping to add documentation and regression tests for interval- >day over the next couple of days and have that readyfor 8.1 as well. Michael Glaesemann grzm myrealbox com
On Jun 21, 2005, at 1:03 PM, Bruce Momjian wrote: > We have addressed all the open issues for 8.1 except for auto-vacuum, > which Alvaro is working on, so I think we are ready for a feature > freeze > on July 1. > I'm hoping to add documentation and regression tests for interval- >day over the next couple of days and have that readyfor 8.1 as well. Michael Glaesemann grzm myrealbox com
People: Oh, and in implementing the COPY stuff we realized that there weren't any regression tests for encodings. If we can figure out how to do them, we'll add those. Are new regression tests permitted during beta? -- --Josh Josh Berkus Aglio Database Solutions San Francisco
Bruce Momjian wrote: > Dave Page wrote: > > Basically, Andreas' approach for 8.0 was to develop a patch (without > posting a proposal or interface), and then argue why pgadmin needs it, > but without addressing the real concerns about the patch. Extending the logging was to get a means of reading the log file without console access, with *any* client. The proposal to develop the generic file functions came from a Mr Bruce Momjian. > Saying > pgadmin needs it just isn't enough to get a patch in. Never said that. It's needed by dbadmins without console access. > There are the > issues of security and maintainability that have to be addressed, All issues were discussed and solved. > and > in the limited time we had to do this in 8.0, it was clear the patch > should not be applied. > > Now, in 8.1, the same thing has happened. Two weeks before feature > freeze, I posted it on June 1st. with no discussion, the patch appears, and makes no reference to > concerns raised during the 8.0 discussion. RTFM. The lengthy original discussion which addressed _all_ issues is referenced. pg_terminate_backend is even > in the patch, and there is no mention or attempt to address concerns we > had in 8.0. I never intended to address the issues, I wanted to address the every day problem to kill a backend without killing the server. Drop it, for god's sake. > > The move of dbsize into the backend is similar. He moves the parts of > dbsize the pgadmin needs into the backend, but makes no mention or > change to /contrib/dbsize to adjust it to the movement of the code. He > has since posted and updated version that fixes this, I think, but > again, we have to discuss how this is to be done --- do we move all the > dbsize functions into the backend, some, or none? Do the other dbsize > functions stay in /contrib or get deleted? > This needs discussion, not a patch. And because there are so many > assumptions made in the patch, the patch committers look unreasonable > asking for X changes to his patch, when in fact he made X assumptions in > the patch and never asked anyone before developing the patch about those > assumptions. This was discussed lengthy starting May 11th, except for the broken dbsize functions. My post is the result from that. Regards, Andreas
On Tue, 21 Jun 2005, Josh Berkus wrote: > People: > > Oh, and in implementing the COPY stuff we realized that there weren't any > regression tests for encodings. If we can figure out how to do them, > we'll add those. Are new regression tests permitted during beta? Yes, most definitely ... especially if they happen to pick up a bug at the same time :) Anything that improves *testing* or *documentation* should be no-brainers for addition during the release process, since they both improve the end product without affecting the backend code itself ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Josh Berkus <josh@agliodbs.com> writes:
> Oh, and in implementing the COPY stuff we realized that there weren't any
> regression tests for encodings. If we can figure out how to do them,
> we'll add those. Are new regression tests permitted during beta?
Certainly. Feature freeze is about features, not correctness ...
regards, tom lane
Andreas Pflug wrote: > Bruce Momjian wrote: > > Dave Page wrote: > > > > Basically, Andreas' approach for 8.0 was to develop a patch (without > > posting a proposal or interface), and then argue why pgadmin needs it, > > but without addressing the real concerns about the patch. > > Extending the logging was to get a means of reading the log file without > console access, with *any* client. > The proposal to develop the generic file functions came from a Mr Bruce > Momjian. Yes, you are right I helped with the initial file stuff, but not with the terminate nor the dbsize. I can't remember if I got involved before or after the initial patch, so you are right. > > Saying > > pgadmin needs it just isn't enough to get a patch in. > > Never said that. It's needed by dbadmins without console access. Needed and having it added are different issues. As I remember there were security concerns about having the backend able to read/write random files. > > There are the > > issues of security and maintainability that have to be addressed, > > All issues were discussed and solved. I am not aware they were all addressed, and if you had terminate in there, which was clearly not addressed, I question whether the others issues are addressed too. I think we need to re-discuss the idea of these functions. > > and > > in the limited time we had to do this in 8.0, it was clear the patch > > should not be applied. > > > > Now, in 8.1, the same thing has happened. Two weeks before feature > > freeze, > > I posted it on June 1st. Uh, you are right it wasn't June 22, but it was June 10, not June 1: http://archives.postgresql.org/pgsql-patches/2005-06/msg00226.php > > with no discussion, the patch appears, and makes no reference to > > concerns raised during the 8.0 discussion. > > RTFM. The lengthy original discussion which addressed _all_ issues is > referenced. Is that true? I don't remember that conclusion myself. Do others? > pg_terminate_backend is even > > in the patch, and there is no mention or attempt to address concerns we > > had in 8.0. > > I never intended to address the issues, I wanted to address the every > day problem to kill a backend without killing the server. Drop it, for > god's sake. Well, here you are saying you didn't address concerns about terminate, and just posted it because it was needed. That is my point. > > The move of dbsize into the backend is similar. He moves the parts of > > dbsize the pgadmin needs into the backend, but makes no mention or > > change to /contrib/dbsize to adjust it to the movement of the code. He > > has since posted and updated version that fixes this, I think, but > > again, we have to discuss how this is to be done --- do we move all the > > dbsize functions into the backend, some, or none? Do the other dbsize > > functions stay in /contrib or get deleted? > > This needs discussion, not a patch. And because there are so many > > assumptions made in the patch, the patch committers look unreasonable > > asking for X changes to his patch, when in fact he made X assumptions in > > the patch and never asked anyone before developing the patch about those > > assumptions. > > This was discussed lengthy starting May 11th, except for the broken > dbsize functions. My post is the result from that. Really? Where? I don't remember anything about it. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
On Tue, 21 Jun 2005, Bruce Momjian wrote: > I am not aware they were all addressed, and if you had terminate in > there, which was clearly not addressed, I question whether the others > issues are addressed too. I think we need to re-discuss the idea of > these functions. Just curious, but if 'all issues were discussed', maybe instead of 're-discussing' it, why not just read through the archives that should be available of that discussion ... ? ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Bruce Momjian wrote: > We have addressed all the open issues for 8.1 except for auto-vacuum, > which Alvaro is working on, so I think we are ready for a feature freeze > on July 1. It would be nice to upgrade to autoconf 2.59 before the freeze (although it would probably be okay to do this post-freeze but pre-beta). -Neil
Dear Stephen, > I'd really like to see role support added into 8.1. I'm also pretty interested in this, and was planing loosely to think about implementing roles someday. It is even better if it is done by someone else;-) > I've sent Alvaro and Tom versions of the patch in the past and I was > planning on submitting it to -patches soon. There's a few remaining > issue but I don't think they'll take very long to clean up; I've just > been unfortunately pretty busy lately. I'm hopeful that I'll be able to > spend some time on it this week and next week to hopefully address at > least the remaining issues on my list. I could not find this patch, although I wanted to have a look. After some thinking on the subjet, ISTM that there are 4 key issues for roles to be really interesting in postgresql, and I just wanted to state them: (1) the role rights should *supercede* group/user rights. E.g. if an admin chose to act in the role "readonly-client", then it should be restricted to what this role allows. (2) roles should be per *catalog* (database), not per cluster (installation) as "user" and "group". (3) role management should be a natural privilege of the database *owner*. (4) user/group/role will make "permission denied" errors even harder to comprehend and solve as they are already, so insteadof "permission denied on table foo", give a more precise form such as "permission denied on table foo, cannotperform update in role bla". Otherwise ISTM that role would not be an improvement over the current "group" concept in postgresql. Maybe it is already what was submitted, but as I could not check... Thanks for working on this useful feature, have a nice day, -- Fabien.
Bruce Momjian wrote: > Andrew Dunstan wrote: > > There is also the tiny patch to trap lexical warnings I submitted not > > long ago still outstanding. > > OK, I missed that one. I see it at: > > http://archives.postgresql.org/pgsql-patches/2005-06/msg00280.php I applied the attached patch from the following URL. The URL does not have separate file names for the regression tests so I did not add those. Thanks. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 Index: src/pl/plperl/GNUmakefile =================================================================== RCS file: /cvsroot/pgsql/src/pl/plperl/GNUmakefile,v retrieving revision 1.22 retrieving revision 1.23 diff -c -r1.22 -r1.23 *** src/pl/plperl/GNUmakefile 24 May 2005 17:07:41 -0000 1.22 --- src/pl/plperl/GNUmakefile 6 Jul 2005 22:33:39 -0000 1.23 *************** *** 1,5 **** # Makefile for PL/Perl ! # $PostgreSQL: pgsql/src/pl/plperl/GNUmakefile,v 1.22 2005/05/24 17:07:41 tgl Exp $ subdir = src/pl/plperl top_builddir = ../../.. --- 1,5 ---- # Makefile for PL/Perl ! # $PostgreSQL: pgsql/src/pl/plperl/GNUmakefile,v 1.23 2005/07/06 22:33:39 momjian Exp $ subdir = src/pl/plperl top_builddir = ../../.. *************** *** 37,43 **** SHLIB_LINK = $(perl_embed_ldflags) $(BE_DLLLIBS) REGRESS_OPTS = --dbname=$(PL_TESTDB) --load-language=plperl ! REGRESS = plperl plperl_trigger plperl_shared include $(top_srcdir)/src/Makefile.shlib --- 37,43 ---- SHLIB_LINK = $(perl_embed_ldflags) $(BE_DLLLIBS) REGRESS_OPTS = --dbname=$(PL_TESTDB) --load-language=plperl ! REGRESS = plperl plperl_trigger plperl_shared plperl_elog include $(top_srcdir)/src/Makefile.shlib Index: src/pl/plperl/plperl.c =================================================================== RCS file: /cvsroot/pgsql/src/pl/plperl/plperl.c,v retrieving revision 1.79 retrieving revision 1.80 diff -c -r1.79 -r1.80 *** src/pl/plperl/plperl.c 3 Jul 2005 21:56:16 -0000 1.79 --- src/pl/plperl/plperl.c 6 Jul 2005 22:33:39 -0000 1.80 *************** *** 33,39 **** * ENHANCEMENTS, OR MODIFICATIONS. * * IDENTIFICATION ! * $PostgreSQL: pgsql/src/pl/plperl/plperl.c,v 1.79 2005/07/03 21:56:16 tgl Exp $ * **********************************************************************/ --- 33,39 ---- * ENHANCEMENTS, OR MODIFICATIONS. * * IDENTIFICATION ! * $PostgreSQL: pgsql/src/pl/plperl/plperl.c,v 1.80 2005/07/06 22:33:39 momjian Exp $ * **********************************************************************/ *************** *** 190,195 **** --- 190,197 ---- "", "-e", /* all one string follows (no commas please) */ "SPI::bootstrap(); use vars qw(%_SHARED);" + "sub ::plperl_warn { my $msg = shift; &elog(&NOTICE, $msg); } " + "$SIG{__WARN__} = \\&::plperl_warn; " "sub ::mkunsafefunc {return eval(qq[ sub { $_[0] $_[1] } ]); }" }; *************** *** 197,202 **** --- 199,206 ---- "", "-e", /* all one string follows (no commas please) */ "SPI::bootstrap(); use vars qw(%_SHARED);" + "sub ::plperl_warn { my $msg = shift; &elog(&NOTICE, $msg); } " + "$SIG{__WARN__} = \\&::plperl_warn; " "sub ::mkunsafefunc {return eval(" "qq[ sub { use strict; $_[0] $_[1] } ]); }" };
Bruce Momjian wrote: > Bruce Momjian wrote: > > Andrew Dunstan wrote: > > > There is also the tiny patch to trap lexical warnings I submitted not > > > long ago still outstanding. > > > > OK, I missed that one. I see it at: > > > > http://archives.postgresql.org/pgsql-patches/2005-06/msg00280.php > > I applied the attached patch from the following URL. The URL does not > have separate file names for the regression tests so I did not add > those. Never mind, I found the right patch. Will add regressions. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073