[HACKERS] user-based query white list

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

Re: [HACKERS] tsearch_extras extension

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 <tabb...@mit.edu>

Re: [HACKERS] CREATE INDEX CONCURRENTLY?

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

Re: [HACKERS] postgres_fdw foreign keys with default sequence

*.devices (device_id) ); ERROR: referenced relation devices is not a table On Tue, Feb 17, 2015 at 1:08 PM, Tim Kane tim.k...@gmail.com wrote: Hi all, Not sure if this has been reported already, it seems to be a variation on this thread: http://www.postgresql.org/message-id/20130515151059.go4

[HACKERS] postgres_fdw foreign keys with default sequence

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

Re: [HACKERS] [GENERAL] Migrating from 9.2.4 to 9.3.0 with XML DOCTYPE

From: Tom Lane t...@sss.pgh.pa.us 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

Re: [HACKERS] removing old ports and architectures

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 robertmh...@gmail.com wrote: On Thu, Oct 17, 2013 at 5:41 PM, Peter Eisentraut pete...@gmx.net wrote: On 10/17/13 12:45 PM, Robert Haas wrote: The

Re: [HACKERS] Suggestion for concurrent index creation using a single full scan operation

Wow.. thanks guys, really appreciate the detailed analysis. Tim On Wed, Jul 24, 2013 at 4:08 AM, Noah Misch n...@leadboat.com 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

[HACKERS] Suggestion for concurrent index creation using a single full scan operation

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

Re: [HACKERS] plperl crash with Debian 6 (64 bit), pl/perlu, libwww and https

On Mon, Aug 08, 2011 at 01:23:08AM -0600, Alex Hunsaker wrote: On Sun, Aug 7, 2011 at 17:06, Tim Bunce tim.bu...@pobox.com wrote: 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

Re: [HACKERS] vacuumlo patch

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.*=

Re: [HACKERS] vacuumlo patch

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 of

Re: [HACKERS] plperl crash with Debian 6 (64 bit), pl/perlu, libwww and https

); 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

Re: [HACKERS] vacuumlo patch

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

Re: [HACKERS] vacuumlo patch

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 included

Re: [HACKERS] vacuumlo patch

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 LOs

Re: [HACKERS] vacuumlo patch

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

[HACKERS] vacuumlo patch

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

Re: [HACKERS] vacuumlo patch

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 +++

Re: [HACKERS] [BUGS] BUG #6034: pg_upgrade fails when it should not.

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 most

Re: [HACKERS] arrays as pl/perl input arguments [PATCH]

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

Re: [HACKERS] arrays as pl/perl input arguments [PATCH]

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

Re: [HACKERS] Optimize PL/Perl function argument passing [PATCH]

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 isPL_sv_no all the time? Maybe we'll have a use for it in the future, but right now we don't

Re: [HACKERS] arrays as pl/perl input arguments [PATCH]

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 :) I'd kind'a hoped that this functionality could be tied

Re: [HACKERS] Optimize PL/Perl function argument passing [PATCH]

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 Buncetim.bu...@pobox.com wrote: Changes: Sets the local $_TD via C instead of passing an extra argument. So functions no longer start

Re: [HACKERS] arrays as pl/perl input arguments [PATCH]

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 mailing list (pgsql-hackers@postgresql.org

Re: [HACKERS] Optimize PL/Perl function argument passing [PATCH]

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 maybe $hashref = decode_hstore_literal('x=1, y=2'). I don't

Re: [HACKERS] Optimize PL/Perl function argument passing [PATCH]

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 $_TD = shift; Pre-extend stack for trigger

[HACKERS] Optimize PL/Perl function argument passing [PATCH]

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.c b/src/pl/plperl

Re: [HACKERS] SHOW TABLES

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

Re: [HACKERS] SHOW TABLES

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 fractional precision is fixed. Not only petrol stations split cents. Tim -- Sent via pgsql-hackers mailing list

Re: [HACKERS] cvs to git migration - keywords

(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

PL/Perl function naming (was: [HACKERS] release notes)

[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: Andrew Dunstan

Re: [HACKERS] release notes

On Mon, May 17, 2010 at 11:34:37AM -0400, Tom Lane wrote: Andrew Dunstan and...@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

Re: [HACKERS] Core dump running PL/Perl installcheck with bleadperl [PATCH]

On Sun, Mar 07, 2010 at 12:11:26PM -0500, Tom Lane wrote: Tim Bunce tim.bu...@pobox.com 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 between SvTYPE(sv

Re: [HACKERS] Safe security

, 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 *** a/doc/src/sgml/plperl.sgml --- b/doc/src/sgml/plperl.sgml *** $$ LANGUAGE plperl; *** 856,862

Re: [HACKERS] Safe security

On Mon, Mar 08, 2010 at 11:03:27AM -0500, Tom Lane wrote: Tim Bunce tim.bu...@pobox.com 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.25 (which has assorted fixes

[HACKERS] Core dump running PL/Perl installcheck with bleadperl [PATCH]

is 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 --git a/src/pl

[HACKERS] Safe security (was: plperl _init settings)

://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 mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

Re: [HACKERS] PostgreSQL::PLPerl::Call - Simple interface for calling SQL functions from PostgreSQL PL/Perl

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 end up caching a lot of extra stuff that would

Re: [HACKERS] CommitFest Status Summary - 2010-02-14

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's 2.22. 2.21 is already dead. Oops, typo

Re: [HACKERS] CommitFest Status Summary - 2010-02-14

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) To make changes to your subscription: http

Re: [HACKERS] PostgreSQL::PLPerl::Call - Simple interface for calling SQL functions from PostgreSQL PL/Perl

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 called with. Why? It keeps the code simple

Re: [HACKERS] GUC failure on exception

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 plperl.use_strict

Re: [HACKERS] PostgreSQL::PLPerl::Call - Simple interface for calling SQL functions from PostgreSQL PL/Perl

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 paramTypes Oid values of 0. Yes

Re: [HACKERS] PostgreSQL::PLPerl::Call - Simple interface for calling SQL functions from PostgreSQL PL/Perl

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. For example: 'pi()' 'generate_series

Re: [HACKERS] CommitFest Status Summary - 2010-02-14

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 to try to wrap things up. * Package namespace and Safe

Re: [HACKERS] PostgreSQL::PLPerl::Call - Simple interface for calling SQL functions from PostgreSQL PL/Perl

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 great. Thanks! PostgreSQL::PLPerl::Call - Simple

Re: [HACKERS] PostgreSQL::PLPerl::Call - Simple interface for calling SQL functions from PostgreSQL PL/Perl

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 in the next week or so. I'd greatly appreciate

Re: [HACKERS] CommitFest Status Summary - 2010-02-14

(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 tim.bu...@pobox.com Date: Mon Feb 15 11:18:07 2010 + Move on_proc_exit

Re: [HACKERS] PostgreSQL::PLPerl::Call - Simple interface for calling SQL functions from PostgreSQL PL/Perl

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 = get_call('nextval(regclass)'); $foo1 = $seq_fn-($seq1

Re: [HACKERS] PostgreSQL::PLPerl::Call - Simple interface for calling SQL functions from PostgreSQL PL/Perl

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) test script. I plan to release

Re: [HACKERS] PostgreSQL::PLPerl::Call - Simple interface for calling SQL functions from PostgreSQL PL/Perl

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. I could allow call('foo', @args), which could

Re: [HACKERS] Package namespace and Safe init cleanup for plperl [PATCH]

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. That makes me quite nervous, which is why I'm raising it now. Tim mentioned in his reply that he'd be happy to put warnings in plc_safe_ok.pl. But that file only

Re: [HACKERS] Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH]

'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

[HACKERS] PostgreSQL::PLPerl::Call - Simple interface for calling SQL functions from PostgreSQL PL/Perl

('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 script. I plan to release the module to CPAN in the next week or so. I'd greatly appreciate any feedback. Tim. =head1 NAME PostgreSQL::PLPerl::Call - Simple

[HACKERS] Re: PostgreSQL::PLPerl::Call - Simple interface for calling SQL functions from PostgreSQL PL/Perl

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 /Users/timbo/pg

Re: [HACKERS] Package namespace and Safe init cleanup for plperl [PATCH]

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) interface should look for 9.1 ... I know Tim mentioned David as having some use cases (cc'ed) I've just

Re: [HACKERS] Add on_plperl_init and on_plperlu_init to plperl UPDATE 3 [PATCH]

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 plperl.on_plperl_init and plperl.on_plperlu_init GUCs Both

Re: [HACKERS] Add on_plperl_init and on_plperlu_init to plperl UPDATE 3 [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 version are in the docs, as I outlined in the previous message. I'll add

Re: [HACKERS] Add on_plperl_init and on_plperlu_init to plperl UPDATE 3 [PATCH]

[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 version

Re: [HACKERS] damage control mode

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 pgsql-hackers mailing

[HACKERS] Add on_plperl_init and on_plperlu_init to plperl UPDATE 3 [PATCH]

. - 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/plperl.sgml

Re: [HACKERS] Confusion over Python drivers

://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/pgsql_perl5/ last updated in 2000. Tim. -- Sent via

Re: [HACKERS] Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH]

On Tue, Feb 02, 2010 at 08:42:21PM -0700, Alex Hunsaker wrote: On Sat, Jan 30, 2010 at 08:49, Tim Bunce tim.bu...@pobox.com 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 was the main

Re: [HACKERS] Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH]

On Wed, Feb 03, 2010 at 10:18:51AM -0700, Alex Hunsaker wrote: On Wed, Feb 3, 2010 at 09:31, Tim Bunce tim.bu...@pobox.com wrote: On Tue, Feb 02, 2010 at 08:42:21PM -0700, Alex Hunsaker wrote: On Sat, Jan 30, 2010 at 08:49, Tim Bunce tim.bu...@pobox.com wrote:    SPI functions

Re: [HACKERS] Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH]

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

Re: [HACKERS] Package namespace and Safe init cleanup for plperl UPDATE 3 [PATCH]

On Mon, Feb 01, 2010 at 07:53:05PM -0700, Alex Hunsaker wrote: On Mon, Feb 1, 2010 at 03:58, Tim Bunce tim.bu...@pobox.com 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 slip-up when I merged

Re: [HACKERS] Package namespace and Safe init cleanup for plperl UPDATE 3 [PATCH]

On Sat, Jan 30, 2010 at 06:38:59PM -0700, Alex Hunsaker wrote: On Sat, Jan 30, 2010 at 16:16, Tim Bunce tim.bu...@pobox.com 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 $PostgreSQL$ keyword

Re: [HACKERS] Package namespace and Safe init cleanup for plperl UPDATE 3 [PATCH]

On Mon, Feb 01, 2010 at 10:46:10AM -0500, Robert Haas wrote: On Mon, Feb 1, 2010 at 5:58 AM, Tim Bunce tim.bu...@pobox.com 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 worked

[HACKERS] Re: Add on_perl_init and proper destruction to plperl UPDATE v3 [PATCH]

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 with Tom Lane and others. Changes in this patch

Re: [HACKERS] Package namespace and Safe init cleanup for plperl [PATCH]

? It just makes the file more self-contained for syntax checking: perl -cw plc_safeboot.pl Other than those really quite minor questions that are arguably me nitpicking... It looks great to me. Great, thanks Alex! Tim. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org

[HACKERS] Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH]

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 be aborted

Re: [HACKERS] Package namespace and Safe init cleanup for plperl [PATCH]

On Sat, Jan 30, 2010 at 11:08:26AM -0700, Alex Hunsaker wrote: On Sat, Jan 30, 2010 at 07:51, Tim Bunce tim.bu...@pobox.com 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 nitpicking...  It looks

[HACKERS] Package namespace and Safe init cleanup for plperl UPDATE 3 [PATCH]

. - 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/pl/plperl/expected/plperl.out --- b/src/pl/plperl/expected/plperl.out *** CONTEXT: PL/Perl

Re: [HACKERS] Add on_perl_init and proper destruction to plperl UPDATED [PATCH]

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 discussions with Tom Lane and others. Changes in this patch

Re: [HACKERS] plperl compiler warning

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.8.x and the notnull attributes

[HACKERS] Add on_perl_init and proper destruction to plperl UPDATE v3 [PATCH]

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/src/sgml/plperl.sgml

Re: [HACKERS] Add on_perl_init and proper destruction to plperl [PATCH]

On Wed, Jan 27, 2010 at 06:33:19PM -0500, Tom Lane wrote: Tim Bunce tim.bu...@pobox.com 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 of the backend --- there's actually

Re: [HACKERS] Add on_perl_init and proper destruction to plperl [PATCH]

On Wed, Jan 27, 2010 at 06:27:50PM -0500, Tom Lane wrote: Tim Bunce tim.bu...@pobox.com 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 could use use

Re: [HACKERS] plperl compiler warning

= 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 subscription: http

[HACKERS] Add on_perl_init and proper destruction to plperl UPDATED [PATCH]

. 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 /para /sect1 ! sect1 id=plperl-missing titleLimitations

Re: [HACKERS] Add on_perl_init and proper destruction to plperl [PATCH]

On Thu, Jan 28, 2010 at 10:39:33AM -0500, Tom Lane wrote: Tim Bunce tim.bu...@pobox.com 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 from using SPI

Re: [HACKERS] Add on_trusted_init and on_untrusted_init to plperl [PATCH]

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 +, Tim Bunce wrote: This is the fourth of the patches to be split out from the former 'plperl feature patch 1'. Changes in this patch: I think

Re: [HACKERS] plperl compiler warning

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 old (gcc 4.2.1). Patch attached. Tim. diff --git a/src/pl/plperl/plperl.c b/src/pl/plperl/plperl.c index 9277072..2dd3458

Re: [HACKERS] Add on_trusted_init and on_untrusted_init to plperl [PATCH]

. 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

Re: [HACKERS] Add on_trusted_init and on_untrusted_init to plperl [PATCH]

On Thu, Jan 28, 2010 at 11:54:08AM -0500, Tom Lane wrote: Tim Bunce tim.bu...@pobox.com 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 are not available when the code is run

Re: [HACKERS] Add on_perl_init and proper destruction to plperl [PATCH]

On Wed, Jan 27, 2010 at 01:14:16AM -0500, Tom Lane wrote: Andrew Dunstan and...@dunslane.net 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 normal interpreter destruction behaviour END

Re: [HACKERS] Add on_perl_init and proper destruction to plperl [PATCH]

On Wed, Jan 27, 2010 at 11:13:43AM -0500, Tom Lane wrote: Tim Bunce tim.bu...@pobox.com 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, during the shutdown sequence

Re: [HACKERS] Add on_perl_init and proper destruction to plperl [PATCH]

On Wed, Jan 27, 2010 at 12:08:48PM -0500, Tom Lane wrote: Tim Bunce tim.bu...@pobox.com 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 the sort of random user

Re: [HACKERS] Add on_perl_init and proper destruction to plperl [PATCH]

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

Re: [HACKERS] Add on_perl_init and proper destruction to plperl [PATCH]

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't involve plperl at all. (Alternatively I

Re: [HACKERS] Miscellaneous changes to plperl [PATCH]

On Sat, Jan 23, 2010 at 06:40:03PM -0700, Alex Hunsaker wrote: On Sat, Jan 23, 2010 at 16:16, Tim Bunce tim.bu...@pobox.com wrote: On Fri, Jan 22, 2010 at 08:59:10PM -0700, Alex Hunsaker wrote: On Thu, Jan 14, 2010 at 09:07, Tim Bunce tim.bu...@pobox.com wrote: I'd vote for use warnings

Re: [HACKERS] Miscellaneous changes to plperl [PATCH]

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 anyway to make a patch that applies cleanly. I want to deal

Re: [HACKERS] Package namespace and Safe init cleanup for plperl [PATCH]

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 - Restructured Safe compartment setup

Re: [HACKERS] Miscellaneous changes to plperl [PATCH]

On Fri, Jan 22, 2010 at 08:59:10PM -0700, Alex Hunsaker wrote: On Thu, Jan 14, 2010 at 09:07, Tim Bunce tim.bu...@pobox.com wrote: - Allow (ineffective) use of 'require' in plperl    If the required module is not already loaded then it dies.    So use strict; now works in plperl. [ BTW I

Re: [HACKERS] warn in plperl logs as... NOTICE??

::PLPerlInit;' You could get more fancy and employ some logic to using WARNING for the first instance of any given message text and NOTICE for subsequent ones. Tim. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org

[HACKERS] Helping the CommitFest re PL/Perl changes

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

[HACKERS] Miscellaneous changes to plperl [PATCH]

is broken for PL/Perl. http://rt.perl.org/rt3/Ticket/Display.html?id=72068 - Assorted minor optimizations by pre-growing data structures. This patch will apply cleanly over the 'add functions' patch: https://commitfest.postgresql.org/action/patch_view?id=264 Tim. diff --git a/doc/src/sgml

Re: [HACKERS] Miscellaneous changes to plperl [PATCH]

On Thu, Jan 14, 2010 at 09:34:42AM -0800, David E. Wheeler wrote: On Jan 14, 2010, at 8:07 AM, Tim Bunce wrote: - Stored procedure subs are now given names. The names are not visible in ordinary use, but they make tools like Devel::NYTProf and Devel::Cover _much_ more useful

  1   2   >