Prev: Row-level Locks & SERIALIZABLE transactions, postgres vs. Oracle
Next: [HACKERS] message style for errcontext
From: Bruce Momjian on 26 May 2010 21:45
Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
> > Andrew Dunstan <andrew(a)dunslane.net> writes:
> >
> >> OK ... I guess I was bothered because this has been referred to in a
> >> public press release about the Beta. The PLPerl security stuff is
> >> missing too, so I'll fix that also.
> >>
> >
> > The security stuff isn't relevant to the 9.0 notes, since it's already
> > been fixed in a previous release. In general we don't document bug
> > fixes in a major release if they already appeared in previous
> > back-patches; the major release notes are quite verbose enough without
> > such duplication. (In effect, the idea is that major release notes
> > should represent the delta from the previous major release *as it stood
> > at the time of the new major release*.)
> >
>
>
> OK, then I will just remove the now redundant item regarding Safe.pm.

Yes, please make whatever updates to the release notes you feel are
appropriate.

--
Bruce Momjian <bruce(a)momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Andrew Dunstan on 30 May 2010 18:58


Tim Bunce wrote:
> On Mon, May 17, 2010 at 11:34:37AM -0400, Tom Lane wrote:
>
>> Andrew Dunstan <andrew(a)dunslane.net> writes:
>>
>>> Why do the release notes say this, under plperl:
>>> * PL/Perl subroutines are now given names (Tim Bunce)
>>> This is for the use of profiling and code coverage tools. DIDN'T
>>> THEY HAVE NAMES BEFORE?
>>>
>>> If whoever put this in the release notes had bothered to ask I am sure
>>> we would have been happy to explain.
>>>
>> You don't need to complain, just fix it. The point of the comment is
>> that more explanation is needed.
>>
>
> I think you can just delete it. It's too esoteric to be worth noting.
>
> Tim.
>
> p.s. It also turned to be insufficiently useful for NYTProf since it
> doesn't also update some internals to record the 'filename' and line
> number range of the sub. So PostgreSQL::PLPerl::NYTProf works around
> that by wrapping mkfuncsrc() to edit the generated perl code to include
> a subname in the usual "sub $name { ... }" style. I may offer a patch
> for 9.1 to to make it work that way.
>
>
I put this aside to think about it.

If the "feature" is not any use should we rip it out? We pretty much
included it because you said it was what you needed for the profiler.

I'm seriously nervous about adding function names - making functions
directly callable like that could be a major footgun recipe, since now
we are free to hide some stuff in the calling mechanism, and can (and
have in the past) changed that to suit our needs, e.g. when we added
trigger support via a hidden function argument. That has been safe
precisely because nobody has had a handle on the subroutine which would
enable it to be called directly from perl code. There have been
suggestions in the past of using this for other features, so we should
not assume that the calling mechanism is fixed in stone.

Perhaps we could decorate the subs with attributes, or is that not
doable for anonymous subs?

cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Robert Haas on 9 Jun 2010 15:11
On Sun, May 30, 2010 at 6:58 PM, Andrew Dunstan <andrew(a)dunslane.net> wrote:
> Tim Bunce wrote:
>> p.s. It also turned to be insufficiently useful for NYTProf since it
>> doesn't also update some internals to record the 'filename' and line
>> number range of the sub. So PostgreSQL::PLPerl::NYTProf works around
>> that by wrapping mkfuncsrc() to edit the generated perl code to include
>> a subname in the usual "sub $name { ... }" style. I may offer a patch
>> for 9.1 to to make it work that way.
>
> I put this aside to think about it.
>
> If the "feature" is not any use should we rip it out? We pretty much
> included it because you said it was what you needed for the profiler.
>
> I'm seriously nervous about adding function names - making functions
> directly callable like that could be a major footgun recipe, since now we
> are free to hide some stuff in the calling mechanism, and can (and have in
> the past) changed that to suit our needs, e.g. when we added trigger support
> via a hidden function argument. That has been safe precisely because nobody
> has had a handle on the subroutine which would enable it to be called
> directly from perl code. There have been suggestions in the past of using
> this for other features, so we should not assume that the calling mechanism
> is fixed in stone.
>
> Perhaps we could decorate the subs with attributes, or is that not doable
> for anonymous subs?

This is still on our open items list - should we do anything about it?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

First  |  Prev  | 
Pages: 1 2
Prev: Row-level Locks & SERIALIZABLE transactions, postgres vs. Oracle
Next: [HACKERS] message style for errcontext