This old thread on "user-based query white list" is now nearly 10 years old!
http://grokbase.com/t/postgresql/pgsql-hackers/08c6zh42fa/user-based-query-white-list
Since then, is it now possible to configure a user to only be able to
execute a limited white-listing of queries? Is this something tha
Just following up here since I haven't gotten a reply -- I'd love to work
with someone from the Postgres community on a plan to make the
tsearch_extras functionality available as part of mainline postgres.
-Tim Abbott
On Wed, Feb 3, 2016 at 9:41 PM, Tim Abbott wrote:
> H
This just hit us today... Admittedly on an old cluster still running 9.2,
though I can't see any mention of it being addressed since.
Any chance of getting this on to to-do list?
On Sat, 1 Nov 2014 at 07:45, Simon Riggs wrote:
> On 31 October 2014 17:46, Michael Banck wrote:
>
> > I wonder whet
*.devices (device_id) );
ERROR: referenced relation "devices" is not a table
On Tue, Feb 17, 2015 at 1:08 PM, Tim Kane wrote:
> Hi all,
>
> Not sure if this has been reported already, it seems to be a variation on
> this thread:
>
> http://www.postgresql.org/m
would have
expected foreign keying from a materialised view to behave independently of
the FDW, as if from a regular local table.
FYI, I'm running postgresql 9.3.4
Cheers,
Tim
>
>
> From: Tom Lane
>
> Hm, can you restore it into 9.2 either?
>
> AFAICS, pg_dump has absolutely no idea that it should be worried about the
> value of xmloption, despite the fact that that setting affects what is
> considered valid XML data. What's worse, even if it were attempting to do
Just to be pedantic, commit message shows
"support for Tru64 ended in 201."
I think you mean 2012.
On 18/10/2013 13:41, "Robert Haas" wrote:
>On Thu, Oct 17, 2013 at 5:41 PM, Peter Eisentraut wrote:
>> On 10/17/13 12:45 PM, Robert Haas wrote:
>>> The attached patch, which I propose
Wow.. thanks guys, really appreciate the detailed analysis.
Tim
On Wed, Jul 24, 2013 at 4:08 AM, Noah Misch wrote:
> On Tue, Jul 23, 2013 at 01:06:26PM +0100, Tim Kane wrote:
> > I haven't given this a lot of thought, but it struck me that when
> > rebuilding tables
Hi all,
I haven't given this a lot of thought, but it struck me that when
rebuilding tables (be it for a restore process, or some other operational
activity) - there is more often than not a need to build an index or two,
sometimes many indexes, against the same relation.
It strikes me that in or
On Mon, Aug 08, 2011 at 01:23:08AM -0600, Alex Hunsaker wrote:
> On Sun, Aug 7, 2011 at 17:06, Tim Bunce wrote:
>
> > Localizing an individual element of %SIG works fine.
> > In C that's something like this (untested):
> >
> > hv = gv_fetchpv("
Thanks Josh,
I like the ability to bail out on PQTRANS_INERROR, and I think it's a small
enough fix to be appropriate to include in this patch.
I did consider it before but did not implement it because I am still new to
pgsql-hackers and did not know how off-the-cuff.
So thanks for the big improvem
-wE '$SIG{INT} = sub { say "Foo"}; { local %SIG; kill "INT", $$; };'
Foo
And, even worse, they're not reset at scope exit:
$ perl -wE '$SIG{INT} = sub { say "Foo"}; { local %SIG; $SIG{INT} = sub {say
"Bar" }} kill "INT", $$;'
Bar
That sure seems like a bug (I'll check with the perl5-porters list).
Localizing an individual element of %SIG works fine.
In C that's something like this (untested):
hv = gv_fetchpv("SIG", 0, SVt_PVHV);
keysv = ...SV containing "ALRM"...
he = hv_fetch_ent(hv, keysv, 0, 0);
if (he) { /* arrange to restore existing elem */
save_helem_flags(hv, keysv, &HeVAL(he), SAVEf_SETMAGIC);
}
else { /* arrange to delete a new elem */
SAVEHDELETE(hv, keysv);
}
Tim.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Excerpts from Peter's message On Sun, Aug 7, 2011 at 3:49 AM:
> Please put the new option 'l' in some sensible order in the code and the
> help output (normally alphabetical). Also, there should probably be
> some update to the documentation.
>
I have alphabetized the help output, and one piece
Excerpts from Josh's message On Sun, Aug 7, 2011 at 2:36 AM:
> could we figure out what that limit should be based on
> max_locks_per_transaction?
It would be nice to implement via "-l max" instead of making users do it
manually or something like this "-l $(grep "max_locks_per_transaction.*="
po
Hi Josh,
Thanks for help. Attached is a patch including changes suggested in your
comments.
Excerpts from Josh's message On Sat, Aug 6, 2011 at 9:57 PM:
>
> 1. It wasn't clear to me whether you're OK with Aron's suggested
> tweak, please include it in your patch if so.
>
I decided to and inclu
Hi Aron,
Thanks for the input. The "small change" you suggest would change the
behavior of the patch which I would prefer not to do as I have reasons for
the previous behavior.
Because you gave no reasons and "stop after removing LIMIT LOs" was not
changed to "stop after attempting to remove LIMIT
Updated the patch to also apply when the no-action flag is enabled.
git diff HEAD -- contrib/vacuumlo/vacuumlo.c
diff --git a/contrib/vacuumlo/vacuumlo.c b/contrib/vacuumlo/vacuumlo.c
index f6e2a28..8e9c342 100644
--- a/contrib/vacuumlo/vacuumlo.c
+++ b/contrib/vacuumlo/vacuumlo.c
@@ -48,6 +48,7 @
Hi Álvaro, thanks for the response.
Here is the requested "diff with 3 lines of context":
git diff HEAD -- contrib/vacuumlo/vacuumlo.c
diff --git a/contrib/vacuumlo/vacuumlo.c b/contrib/vacuumlo/vacuumlo.c
index f6e2a28..b7c7d64 100644
--- a/contrib/vacuumlo/vacuumlo.c
+++ b/contrib/vacuumlo/vacu
Please consider adding this minor patch, or offering improvements.
*Problem*: vacuumlo required PostgreSQL to use more locks per transaction
than possible resulting in an error and a log file full of "ignored until
end of transaction" warnings.
(max_locks_per_transaction is limited by shmmax which
> I thought the problem was that they upgraded the OS and now the encoding
> names changed, though they behaved the same. Is that now what is
> happening? Can they supply the values with different cases?
>
In my case I never touched the locale. It was set by the OS. I presume
this is true for m
al,
I'd assume encode_type_literal() encodes a _type_ as a literal.
I'd suggest encode_typed_literal() as a better name.
Tim [just passing though]
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
nions, but...]
I can't see any major issues so I'm happy for you to move ahead.
Thanks!
Tim.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Feb 03, 2011 at 02:23:32PM +0200, Alexey Klyukin wrote:
> Hi,
>
> On Feb 2, 2011, at 7:16 PM, Tim Bunce wrote:
>
> > I'm sorry I'm late to this party. I haven't been keeping up with
> > pgsql-hackers.
>
> Better late than never :)
>
&g
On Wed, Feb 02, 2011 at 12:10:59PM -0500, Andrew Dunstan wrote:
>
> On 02/02/2011 11:45 AM, Tim Bunce wrote:
> >>But why are we bothering to keep $prolog at
> >>all any more, if all we're going to pass it is&PL_sv_no all the
> >>time? Maybe we'll ha
o the overhead of parsing the string and allocating the
array and all its elements.
- Some of those functions may not use the array at all and some may
simply pass it on as an argument to another function.
- Making the conversion lazy would be a big help.
Tim.
--
Sent via pgsql-hackers mailin
On Mon, Jan 31, 2011 at 02:22:37PM -0500, Andrew Dunstan wrote:
>
>
> On 01/15/2011 12:31 AM, Alex Hunsaker wrote:
> >On Tue, Dec 7, 2010 at 07:24, Tim Bunce wrote:
> >>Changes:
> >>
> >>Sets the local $_TD via C instead of passing an extra argu
On Wed, Dec 08, 2010 at 09:21:05AM -0800, David E. Wheeler wrote:
> On Dec 8, 2010, at 9:14 AM, Tim Bunce wrote:
>
> >> Do you have any more improvements in the pipeline?
> >
> > I'd like to add $arrayref = decode_array_literal('{2,3}') and
> > ma
On Tue, Dec 07, 2010 at 10:00:28AM -0500, Andrew Dunstan wrote:
>
>
> On 12/07/2010 09:24 AM, Tim Bunce wrote:
> >Changes:
> >
> > Sets the local $_TD via C instead of passing an extra argument.
> > So functions no longer start with "our $_TD; local
Changes:
Sets the local $_TD via C instead of passing an extra argument.
So functions no longer start with "our $_TD; local $_TD = shift;"
Pre-extend stack for trigger arguments for slight performance gain.
Passes installcheck.
Tim.
diff --git a/src/pl/plperl/plperl.
; would seem odd for a database to tout its ability to deal with such
> data types as geometric shapes and global positioning, etc., which
> then didn't have such a common type as money. In my experience,
> many business applications deal with money.
One major flaw I see is that the f
in this thread is that
there doesn't seem to be a "usually" with regard to "\d"
equivalents either.
Tim
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
herwise be challenging to automatically not
only delete the "$PostgreSQL$" line, but also leading and/or
trailing empty (comment) lines, and not mess up.
Tim
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[Sorry for the delay. I'd stopped checking the pgsql mailing lists.
Thanks to David Wheeler and Josh Berkus for the heads-up.]
On Sun, May 30, 2010 at 06:58:32PM -0400, Andrew Dunstan wrote:
>
> Tim Bunce wrote:
> >On Mon, May 17, 2010 at 11:34:37AM -0400, Tom Lane wrote:
&
On Mon, May 17, 2010 at 11:34:37AM -0400, Tom Lane wrote:
> Andrew Dunstan 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&
On Mon, Mar 08, 2010 at 11:03:27AM -0500, Tom Lane wrote:
> Tim Bunce writes:
> > Here's a patch that:
> > 1. adds wording like that to the docs.
> > 2. randomises the container package name (a simple and sound security
> > measure).
> > 3. requires Safe 2.2
ntainer package name (a simple and sound security measure).
3. requires Safe 2.25 (which has assorted fixes, including security).
4. removed a harmless but suprious exclamation mark from the source.
Tim.
diff --git a/doc/src/sgml/plperl.sgml b/doc/src/sgml/plperl.sgml
index c000463..0cc59c5 100644
*
On Sun, Mar 07, 2010 at 12:11:26PM -0500, Tom Lane wrote:
> Tim Bunce writes:
> > I encountered a core dump running PL/Perl installcheck with a very
> > recent git HEAD of PostgreSQL and a not quite so recent git HEAD of perl.
>
> > The cause is a subtle difference betw
directly checking "does this sv contains a reference".
The attached patch fixes the problem by changing the SvTYPE check to use
SvROK instead. Although I only tripped over one case, the patch changes
all four uses of SvTYPE(sv) == SVt_RV. The remaining uses of SvTYPE are ok.
Tim.
diff --gi
statement than can be justified.
The docs for Safe http://search.cpan.org/~rgarcia/Safe-2.23/Safe.pm#WARNING
say "The authors make no warranty, implied or otherwise, about the
suitability of this software for safety or security purposes".
Tim.
--
Sent via pgsql-hackers maili
On Wed, Feb 17, 2010 at 10:30:03AM -0800, David E. Wheeler wrote:
> On Feb 17, 2010, at 4:28 AM, Tim Bunce wrote:
>
> >> Yes, but if it's a variadic function, I suspect that it won't often be
> >> called with the same number of args. So you'd potentially e
Did this ever get turned into a formal bug report with a number?
Tim.
On Thu, Jan 14, 2010 at 07:39:09PM -0500, Andrew Dunstan wrote:
>
> Tim Bunce just showed me the following oddity:
>
>andrew=# SET SESSION plperl.use_strict = on;
>SET
>andrew=# SHOW
On Tue, Feb 16, 2010 at 02:13:30PM -0800, David E. Wheeler wrote:
> On Feb 16, 2010, at 2:06 PM, Tim Bunce wrote:
>
> >>> For varadic functions, separate plans are created and cached for each
> >>> distinct
> >>> number of arguments the function is call
u back for 9.1)!
Thanks Robert. That's nice to hear.
I'd be happy to do more for 9.1 (subject to the ongoing generosity of my
client http://TigerLead.com who are the ones to thank for my work on
PostgreSQL).
Tim.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
T
On Tue, Feb 16, 2010 at 02:25:00PM -0800, David E. Wheeler wrote:
> On Feb 16, 2010, at 2:19 PM, Tim Bunce wrote:
>
> > p.s. One quick heads-up: David Wheeler has reported a possible issue
> > with Safe 2.21. I hope to investigate that tomorrow.
>
> Actually it'
On Tue, Feb 16, 2010 at 04:42:29PM -0500, Andrew Dunstan wrote:
> Tim Bunce wrote:
> >On Sun, Feb 14, 2010 at 10:14:28PM -0500, Andrew Dunstan wrote:
> >>Robert Haas wrote:
> >>>We're down to 5 patches remaining, and 1 day remaining, so it's time
> >&g
On Tue, Feb 16, 2010 at 09:11:24AM -0800, David E. Wheeler wrote:
> On Feb 16, 2010, at 4:08 AM, Tim Bunce wrote:
>
> From the docs:
>
> > Immediately after the function name, in parenthesis, a comma separated list
> > of
> > type names can be given.
On Mon, Feb 15, 2010 at 02:58:47PM -0800, David E. Wheeler wrote:
> On Feb 15, 2010, at 2:42 PM, Tim Bunce wrote:
>
> > I've not really looked the the DBD::Pg code much so this seemed like a
> > good excuse... It looks like the default is to call PQprepare() with
> &g
On Mon, Feb 15, 2010 at 11:52:01AM -0800, David E. Wheeler wrote:
> On Feb 15, 2010, at 2:51 AM, Tim Bunce wrote:
>
> > The signature doesn't just qualify the selection of the function,
> > it also ensures appropriate interpretation of the arguments.
> >
> &
On Mon, Feb 15, 2010 at 10:51:14AM +, Tim Bunce wrote:
> On Sat, Feb 13, 2010 at 02:25:48PM -0800, David E. Wheeler wrote:
> > On Feb 12, 2010, at 3:10 PM, Tim Bunce wrote:
> >
> > > I've appended the POD documentation and attached the (rough but working)
>
On Mon, Feb 15, 2010 at 10:42:15AM +, Richard Huxton wrote:
> On 15/02/10 10:32, Tim Bunce wrote:
> >On Mon, Feb 15, 2010 at 07:31:14AM +, Richard Huxton wrote:
> >>
> >>Is there any value in having a two-stage interface?
> >>
> >>$seq_fn =
so on_proc_exit will only be called if plperl_*_init() succeeds
(else there's a risk of on_proc_exit consuming all the exit hook slots)
- don't allow use of Safe version 2.21 as that's broken for PL/Perl.
Tim.
commit d8c0d4e63c00606db95f95a9c8f2b7ccf3c819b3
Author: Tim Bunce
On Sat, Feb 13, 2010 at 02:25:48PM -0800, David E. Wheeler wrote:
> On Feb 12, 2010, at 3:10 PM, Tim Bunce wrote:
>
> > I've appended the POD documentation and attached the (rough but working)
> > test script.
> >
> > I plan to release the module to CPAN i
On Mon, Feb 15, 2010 at 07:31:14AM +, Richard Huxton wrote:
> On 12/02/10 23:10, Tim Bunce wrote:
> >There was some discussion a few weeks ago about inter-stored-procedure
> >calling from PL/Perl.
>
> >I'd greatly appreciate any feedback.
>
> Looks gre
cumented it's not supported.
> Another objection is that discussion on this facility has been
> pretty scant. I think that's putting it mildly. Maybe it's been
> apparent to a few people what the implications are, but I doubt it's
> been apparent to many
e trust, or lack of it, placed in DBAs.
> Anyway reasons I can come up for it are:
> -its general so we can add other modules/pragmas easily in the future
> -helps with the plperl/plperlu all or nothing situation
> -starts to flesh out how an actual exposed (read documented) inte
On Fri, Feb 12, 2010 at 11:10:15PM +, Tim Bunce wrote:
> I've appended the POD documentation and attached the (rough but working)
> test script.
Oops. Here's the test script.
Tim.
create or replace function test_call() returns text language plperlu as $func$
use lib
i_fetchrow($sth) ) {
push(@mlx_area_ids, $row->{tl_domain_mlx_area_ids});
}
New:
@mlx_area_ids = call('tl_domain_mlx_area_ids(int,int,int)', $mlx_board_id,
$domain_id, $debug);
I've appended the POD documentation and attached the (rough but working)
test scri
eflect the needed doc changes in
http://archives.postgresql.org/message-id/20100208204213.gh1...@timac.local
That updated patch is in the commitfest
https://commitfest.postgresql.org/action/patch_view?id=271
>From talking to Andrew via IM I understand he's very busy, and also that
he'll be traveling on Sunday and Monday.
I certainly hope he can commit this patch today (along with the next
patch, which is also marked ready for committer) but if not, is there
someone else who could?
What happens to patches marked 'ready for committer' after the
commitfest ends?
Tim.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[Sigh. This email, unlike the previous, actually includes the patch.]
On Mon, Feb 08, 2010 at 01:44:16PM +, Tim Bunce wrote:
>
> > I'll continue reviewing the patch, but these things at least need fixing.
Here's an updated patch. The only changes relative to the previous
On Mon, Feb 08, 2010 at 01:44:16PM +, Tim Bunce wrote:
>
> > I'll continue reviewing the patch, but these things at least need fixing.
Here's an updated patch. The only changes relative to the previous
version are in the docs, as I outlined in the previous message.
On Sun, Feb 07, 2010 at 08:25:33PM -0500, Andrew Dunstan wrote:
> Tim Bunce wrote:
> >This is the third update to the fourth of the patches to be split out
> >from the former 'plperl feature patch 1'.
> >
> >Changes in this patch:
> >
> >- Added
On Sat, Feb 06, 2010 at 10:38:00PM -0800, Josh Berkus wrote:
>
> Add on_trusted_init and on_untrusted_init to plperl
> Package namespace and Safe init cleanup for plperl
Alex Hunsaker has marked the latest version of both of those
as Ready for Committer.
Tim.
--
Sent via pgsq
7;s
only one DBI PostgreSQL driver: http://search.cpan.org/dist/DBD-Pg/
The only non-DBI interfaces I could find (by skimming the 384 results
for postgresql on search.cpan.org) were:
Postgres: http://search.cpan.org/dist/Postgres/last updated in 1998.
Pg: http://search.cpan.org/dist
unchanged.
- The utf8fix code has been greatly simplified.
- More code comments re PGC_SUSET and no access to SPI functions.
Tim.
diff --git a/doc/src/sgml/plperl.sgml b/doc/src/sgml/plperl.sgml
index 7018624..0999bd0 100644
*** a/doc/src/sgml/plperl.sgml
--- b/doc/src/sgml/p
e in plperl in terms of what perl code can be compiled.
It seems there is a plausable vector for trojan-horse code though, so I
think the key issue if this could be exploited in a security definer
scenario.
Tim.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Feb 03, 2010 at 10:18:51AM -0700, Alex Hunsaker wrote:
> On Wed, Feb 3, 2010 at 09:31, Tim Bunce wrote:
> > On Tue, Feb 02, 2010 at 08:42:21PM -0700, Alex Hunsaker wrote:
> >> On Sat, Jan 30, 2010 at 08:49, Tim Bunce wrote:
> >>
> >> > SPI funct
On Tue, Feb 02, 2010 at 08:42:21PM -0700, Alex Hunsaker wrote:
> On Sat, Jan 30, 2010 at 08:49, Tim Bunce wrote:
>
> > SPI functions are not available when the code is run.
>
> Hrm, we might want to stick why in the docs or as a comment somewhere.
> I think this
On Mon, Feb 01, 2010 at 07:53:05PM -0700, Alex Hunsaker wrote:
> On Mon, Feb 1, 2010 at 03:58, Tim Bunce wrote:
> > On Sat, Jan 30, 2010 at 06:38:59PM -0700, Alex Hunsaker wrote:
> >
> >> plc_safe_ok.pl seems to loose its CVS $PostgreSQL$ keyword.
> >Probably a sli
On Mon, Feb 01, 2010 at 10:46:10AM -0500, Robert Haas wrote:
> On Mon, Feb 1, 2010 at 5:58 AM, Tim Bunce wrote:
> > p.s. If there is interest in defining a documented API (for DBAs to
> > control what gets loaded into Safe and shared with it) for *9.0*
> > then that could be
On Sat, Jan 30, 2010 at 06:38:59PM -0700, Alex Hunsaker wrote:
> On Sat, Jan 30, 2010 at 16:16, Tim Bunce wrote:
> > This is an update to the final plperl patch in the series from me.
> >
> > Changes in the original patch:
>
> plc_safe_ok.pl seems to loose its CVS $Pos
Ensure Safe container opmask is restored even if @EvalInSafe code
throws an exception.
- Changed errmsg("didn't get a GLOB ...") to use errmsg_internal().
Tim.
diff --git a/src/pl/plperl/expected/plperl.out b/src/pl/plperl/expected/plperl.out
index ebf9afd..0e7c65d 100644
*** a/src/
On Sat, Jan 30, 2010 at 11:08:26AM -0700, Alex Hunsaker wrote:
> On Sat, Jan 30, 2010 at 07:51, Tim Bunce wrote:
> > On Fri, Jan 29, 2010 at 08:07:30PM -0700, Alex Hunsaker wrote:
> >
> >> Other than those really quite minor questions that are arguably me
> >> ni
en greatly simplified.
Tim.
diff --git a/doc/src/sgml/plperl.sgml b/doc/src/sgml/plperl.sgml
index ea56b99..0add7d1 100644
*** a/doc/src/sgml/plperl.sgml
--- b/doc/src/sgml/plperl.sgml
*** CREATE TRIGGER test_valid_id_trig
*** 1058,1066
or subtransaction to
ible.
> Hrm I also dont see the point of the new "use Safe;" as we still eval
> it in in plperl_safe_init() care to enlighten a lost soul?
It just makes the file more self-contained for syntax checking:
perl -cw plc_safeboot.pl
> Other than those really quite minor question
On Fri, Jan 29, 2010 at 09:10:48PM -0500, Andrew Dunstan wrote:
>
> Tim Bunce wrote:
> >This is an updated version of the third of the patches to be
> >split out from the former 'plperl feature patch 1'.
> >
> >It includes changes following discussions wit
#x27;ve added a note in the Limitations section of the PL/Perl docs.
It also adds a PERL_SET_CONTEXT() that's needed but was missing.
Tim.
diff --git a/doc/src/sgml/plperl.sgml b/doc/src/sgml/plperl.sgml
index 5fa7e3a..c4d5d8e 100644
*** a/doc/src/sgml/plperl.sgml
--- b/doc/
On Thu, Jan 28, 2010 at 07:49:37PM +, Tim Bunce wrote:
>
> I think I missed this because the Xcode compiler on Snow Leopard is
> fairly old (gcc 4.2.1).
For the record, gcc 4.2.1 does report the error. I'd missed it because
I'd done most of my builds with perl 5.
On Thu, Jan 28, 2010 at 11:02:23PM -0500, Andrew Dunstan wrote:
>
>
> Tim Bunce wrote:
> >This is an updated version of the third of the patches to be split out
> >from the former 'plperl feature patch 1'.
> >
> >It includes changes following discussio
On Thu, Jan 28, 2010 at 11:54:08AM -0500, Tom Lane wrote:
> Tim Bunce writes:
> > I think the only controversial change is this one:
>
> >> - Adds plperl.on_trusted_init and plperl.on_untrusted_init GUCs
> >> Both are PGC_USERSET.
> >> SPI functions
he 'untrusted' language is for running 'trusted'
code. The naming convention is unfortunate.
Just an observation from a newbie. I imagine it's been pointed out before.
Tim.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
looks to me like this is probably a live bug not just compiler
> hypersensitivity.
Yes. (ISTR there have been cases where the notnull attribute was
misapplied to some perl functions, but that's not the case here.)
I think I missed this because the Xcode compiler on Snow Leopard is
fairly ol
Now the dust is settling on the on_perl_init patch I'd like to ask for
clarification on this next patch.
On Fri, Jan 15, 2010 at 12:35:06AM +0000, Tim Bunce wrote:
> This is the fourth of the patches to be split out from the former
> 'plperl feature patch 1'.
>
> Chan
On Thu, Jan 28, 2010 at 10:39:33AM -0500, Tom Lane wrote:
> Tim Bunce writes:
> > On Wed, Jan 27, 2010 at 06:27:50PM -0500, Tom Lane wrote:
> >> An advantage of on_proc_exit from your end is that it should allow
> >> you to not have to try to prevent the END blocks f
this time.
Tim.
diff --git a/doc/src/sgml/plperl.sgml b/doc/src/sgml/plperl.sgml
index 5fa7e3a..06c63df 100644
*** a/doc/src/sgml/plperl.sgml
--- b/doc/src/sgml/plperl.sgml
*** CREATE TRIGGER test_valid_id_trig
*** 1028,1034
!
Limitations and Missin
is:
subref = newRV_inc((SV*)GvCVu((GV*)sub_glob));
Does that match yours? (If not, what is the text on the line?)
What perl version are you using?
What compiler version are you using?
Tim.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your sub
On Wed, Jan 27, 2010 at 06:27:50PM -0500, Tom Lane wrote:
> Tim Bunce writes:
> > Okay. I could change the callback code to ignore calls if
> > proc_exit_inprogress is false. So an abnormal shutdown via exit()
> > wouldn't involve plperl at all. (Alternatively I coul
On Wed, Jan 27, 2010 at 06:33:19PM -0500, Tom Lane wrote:
> Tim Bunce writes:
> > On Wed, Jan 27, 2010 at 11:28:02AM -0500, Tom Lane wrote:
> >> Really? We've found that gprof, for instance, doesn't exactly have
> >> "zero interaction with the rest o
On Wed, Jan 27, 2010 at 01:51:47PM -0800, David E. Wheeler wrote:
> On Jan 27, 2010, at 1:27 PM, Tim Bunce wrote:
>
> > Okay. I could change the callback code to ignore calls if
> > proc_exit_inprogress is false. So an abnormal shutdown via exit()
> > wouldn
PgPLPerl
> But in any case, I don't believe for a moment that profiling is the only
> or even the largest use to which people would try to put this.
Can you give any examples?
Tim.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Jan 27, 2010 at 12:08:48PM -0500, Tom Lane wrote:
> Tim Bunce writes:
> > On Wed, Jan 27, 2010 at 11:13:43AM -0500, Tom Lane wrote:
> >> (In particular note that shutdown itself might be fired as an atexit
> >> callback, a move forced on us by exactly t
On Wed, Jan 27, 2010 at 11:13:43AM -0500, Tom Lane wrote:
> Tim Bunce writes:
> > On Wed, Jan 27, 2010 at 12:46:42AM -0700, Alex Hunsaker wrote:
> >> FWIW the atexit scares me to.
>
> > In what way, specifically?
>
> It runs too late, and too unpredictably, du
On Wed, Jan 27, 2010 at 01:14:16AM -0500, Tom Lane wrote:
> Andrew Dunstan writes:
> > Tim Bunce wrote:
> >> - Added plperl.on_perl_init GUC for DBA use (PGC_SIGHUP)
> >> SPI functions are not available when the code is run.
> >>
> >> - Added norm
On Wed, Jan 27, 2010 at 12:46:42AM -0700, Alex Hunsaker wrote:
> On Tue, Jan 26, 2010 at 23:14, Tom Lane wrote:
> > Andrew Dunstan writes:
> >> Tim Bunce wrote:
> >>> - Added plperl.on_perl_init GUC for DBA use (PGC_SIGHUP)
> >>> SPI functi
On Fri, Jan 15, 2010 at 04:02:02AM +, Tim Bunce wrote:
> This is the final plperl patch in the series from me.
>
> Changes in this patch:
>
> - Moved internal functions out of main:: namespace
> into PostgreSQL::InServer and PostgreSQL::InServer::safe
>
> - Restr
On Mon, Jan 25, 2010 at 11:09:12AM -0500, Andrew Dunstan wrote:
>
> Tim Bunce wrote:
> >
> >FYI I've an updated patch ready but I'll wait till the commitfest has
> >got 'closer' as there's a fair chance a further update will be needed
> >anyw
On Sat, Jan 23, 2010 at 06:40:03PM -0700, Alex Hunsaker wrote:
> On Sat, Jan 23, 2010 at 16:16, Tim Bunce wrote:
> > On Fri, Jan 22, 2010 at 08:59:10PM -0700, Alex Hunsaker wrote:
> >> On Thu, Jan 14, 2010 at 09:07, Tim Bunce wrote:
> >> I'd vote for use warni
On Fri, Jan 22, 2010 at 08:59:10PM -0700, Alex Hunsaker wrote:
> On Thu, Jan 14, 2010 at 09:07, Tim Bunce wrote:
> > - Allow (ineffective) use of 'require' in plperl
> > If the required module is not already loaded then it dies.
> > So "use strict;"
ld be handled via plperl.on_perl_init:
plperl.on_perl_init='$SIG{__WARN__} = sub { elog(WARNING, shift) }'
or
plperl.on_perl_init='use lib "/MyApp/lib"; use MyApp::PLPerlInit;'
You could get more fancy and employ some logic to using WARNING for the
first in
What can I do to help the CommitFest, especially in relation to the
PL/Perl changes?
Tim.
p.s. I've sent an email to the dbi-users and dbi-announce lists
http://www.mail-archive.com/dbi-us...@perl.org/msg32649.html
in the hope of encouraging some more people to review and test the
patches
.
Neither change has any user visible effects.
This patch will apply cleanly over the 'Add on_trusted_init and
on_untrusted_init to plperl' patch:
https://commitfest.postgresql.org/action/patch_view?id=271
Tim.
diff --git a/src/pl/plperl/plc_perlboot.pl b/src/pl/plperl/plc_perlboot.pl
ind
1 - 100 of 206 matches
Mail list logo
