On Fri, Aug 29, 2008 at 1:16 PM, Tom Lane [EMAIL PROTECTED] wrote:
In theory the above implementation of newNode should be a clear win,
so I'm thinking this result must be an artifact of some kind. I'm
going to go try it on PPC and HPPA machines next; does anyone want to
try it on something
On Thu, Sep 4, 2008 at 12:01 PM, Tom Lane [EMAIL PROTECTED] wrote:
I think what the hash index patch really needs is some performance
testing. I'm willing to take responsibility for the code being okay
or not, but I haven't got any production-grade hardware to do realistic
performance tests
On Mon, Sep 8, 2008 at 2:24 AM, Brendan Jurd [EMAIL PROTECTED] wrote:
HEAD actually gets this one wrong; in defiance of the documentation it
returns 2000-09-07. So, it seems to me that the patch shifts the
behaviour in the right direction.
Barring actually teaching the code that some nodes
On Tue, Sep 9, 2008 at 6:46 AM, Brendan Jurd [EMAIL PROTECTED] wrote:
On Tue, Sep 9, 2008 at 9:04 PM, Brendan Jurd [EMAIL PROTECTED] wrote:
On Tue, Sep 9, 2008 at 7:29 PM, Martijn van Oosterhout
[EMAIL PROTECTED] wrote:
The use of palloc/pfree in this routine seems excessive. Does len have
On Sun, Sep 21, 2008 at 11:09 AM, Tom Lane [EMAIL PROTECTED] wrote:
A possible objection to this plan is that if the column-level privileges
patch doesn't get in, then we're left with a useless column in
pg_attribute. But an always-null column doesn't cost much of anything,
and we know that
On Fri, Sep 26, 2008 at 11:25 AM, Brendan Jurd [EMAIL PROTECTED] wrote:
One way to tidy this up would be to re-implement the meridiem markers
using the seq_search functions, i.e., make it work like the day and
month names. This would make it easy to accept any flavour of marker,
and the error
On Wed, Aug 27, 2008 at 8:54 PM, ITAGAKI Takahiro
[EMAIL PROTECTED] wrote:
Here is a contrib version of auto-explain.
I'd like to add it the next commit-fest in September.
Here is my review:
*custom_guc_flags-0828.patch
It seems to be windows newline damaged? lots of ^M at the end of the
On Fri, Oct 31, 2008 at 07:48, David Fetter [EMAIL PROTECTED] wrote:
Please find attached a patch which works in PL/Perl, the work having
been done by Andrew (RhodiumToad) Gierth. It's not clear to me how
this would be generally surface-able to SQL, though. Any ideas?
I was assigned to
On Thu, Oct 30, 2008 at 05:16, Tom Lane [EMAIL PROTECTED] wrote:
David Fetter [EMAIL PROTECTED] writes:
On Wed, Oct 29, 2008 at 10:23:36PM -0400, Tom Lane wrote:
I would argue that it's already designed wrong if there's need for
PL-specific implementation effort.
I'm not sure how else to do
On Thu, Oct 9, 2008 at 03:06, ITAGAKI Takahiro
[EMAIL PROTECTED] wrote:
Thanks for your reviewing, Alex.
I applied your comments to my patch.
Sorry for the late reply! Somehow I missed this, saw it on the commit
fest wiki :)
*custom_guc_flags-0828.patch
My only other concern is the changes
On Wed, Nov 5, 2008 at 16:00, Kevin Grittner
[EMAIL PROTECTED] wrote:
An idea for a possible enhancement to PostgreSQL: allow creation of a
temporary table without generating any disk I/O. (Creating and
dropping a three-column temporary table within a database transaction
currently generates
On Mon, Oct 20, 2008 at 05:50, Magnus Hagander [EMAIL PROTECTED] wrote:
Attached patch cleans up the certificate verification in libpq, and adds
a configuration paraqmeter to control it. The new parameter is
sslverify, and can be set to:
* cn = default = will validate that the certificate
On Tue, Nov 11, 2008 at 06:16, Magnus Hagander [EMAIL PROTECTED] wrote:
Alex Hunsaker wrote:
On Mon, Oct 20, 2008 at 05:50, Magnus Hagander [EMAIL PROTECTED] wrote:
$ SSLVERIFY=cn ./psql junk -h 192.168.0.2
psql: server common name 'bahdushka' does not match hostname
'192.168.0.2'FATAL
OK now that im using the right env var everything seems to work as
described. FYI I also tried to exercise the various new error paths
and everything seems good so as far as i'm concerned this looks good
to me. Ill go mark it as ready for commiter on the wiki. (whatever
that means you being a
On Thu, Nov 13, 2008 at 01:05, Magnus Hagander [EMAIL PROTECTED] wrote:
It means I will go ahead and apply it once I have looked it over once more.
Thanks for review+testing!
You may now move on to the next ssl patch if you're interested ;)
Sure thing probably wont get to it till tomorrow...
On Thu, Oct 23, 2008 at 08:51, Magnus Hagander [EMAIL PROTECTED] wrote:
Magnus Hagander wrote:
This patch adds a configuration option to pg_hba.conf for clientcert.
This makes it possible to have different client certificate requirements
on different connections. It also makes sure that if you
On Sat, Nov 15, 2008 at 15:20, Alex Hunsaker [EMAIL PROTECTED] wrote:
we do something like:
+ if (access(ROOT_CERT_FILE, R_OK))
+ {
+ ssl_loaded_verify_locations = false;
+
+ /*
+ * If root certificate file simply not found. Don't log
On Thu, Nov 13, 2008 at 05:31, Magnus Hagander [EMAIL PROTECTED] wrote:
Attached patch implements client certificate authentication.
I kept this sitting in my tree without sending it in before the
commitfest because it is entirely dependent on the
not-yet-reviewed-and-applied patch for how to
On Sat, Nov 15, 2008 at 17:39, Tom Lane [EMAIL PROTECTED] wrote:
Alex Hunsaker [EMAIL PROTECTED] writes:
Err that really should be ereport(FATAL,
I don't think that's a particularly user-friendly design.
The behavior I'd expect to see is
1. Root cert file not there: issue existing LOG
On Mon, Nov 17, 2008 at 01:01, Magnus Hagander [EMAIL PROTECTED] wrote:
On 16 nov 2008, at 01.00, Alex Hunsaker [EMAIL PROTECTED] wrote:
Would cncert be a better auth_method name? As later we might have
different types of ssl client cert authentication??
If/when I'd rather still call it cert
On Mon, Nov 17, 2008 at 05:31, Alvaro Herrera
[EMAIL PROTECTED] wrote:
Magnus Hagander escribió:
On 16 nov 2008, at 01.00, Alex Hunsaker [EMAIL PROTECTED] wrote:
My only concern is there is no way to specify the USER_CERT_FILE for
libpq. So if for example I have two users that I want to use
On Mon, Nov 17, 2008 at 03:04, Magnus Hagander [EMAIL PROTECTED] wrote:
Alex Hunsaker wrote:
On Sat, Nov 15, 2008 at 17:39, Tom Lane [EMAIL PROTECTED] wrote:
2. Root cert file present but we fail to load it: FATAL is probably okay
here, but not with that hint message.
Err, I was just trying
On Fri, Aug 1, 2008 at 13:31, Alvaro Herrera [EMAIL PROTECTED] wrote:
Something that's bothering me is that PGSSLKEY is inconsistent with the
sslkey conninfo parameter. PGSSLKEY specifies an engine (basically a
driver for specialized hardware AFAICT) from which the key is to be
loaded, but
On Thu, Nov 20, 2008 at 21:45, Philip Warner [EMAIL PROTECTED] wrote:
Sounds somewhat evil, I know, but I was wondering if it was even
remotely possible with the current design?
The reason: we are contemplating using pg_standy to create a
warm-standby. It would be a bonus if we would run
On Fri, Dec 5, 2008 at 13:58, Andrew Chernow [EMAIL PROTECTED] wrote:
Who anyone be opposed to ssldir = path as a connection option? Currently,
there is no way to change the homedir method ~/.postgresql ... or am I
missing something? I am willing to supply a patch.
You mean something like the
On Fri, Dec 5, 2008 at 14:22, Andrew Chernow [EMAIL PROTECTED] wrote:
Alex Hunsaker wrote:
On Fri, Dec 5, 2008 at 13:58, Andrew Chernow [EMAIL PROTECTED] wrote:
Who anyone be opposed to ssldir = path as a connection option?
Currently,
there is no way to change the homedir method
On Tue, Dec 2, 2008 at 02:35, ITAGAKI Takahiro
[EMAIL PROTECTED] wrote:
Here is an update version of contrib/pg_stat_statements.
Hello again!
I was assigned to review this.
Submission review:
Is the patch in standard form? Yes
Does it apply cleanly to current HEAD? Yes (with fuzz)
Does it
On Tue, Dec 9, 2008 at 01:20, Greg Smith [EMAIL PROTECTED] wrote:
On Sun, 7 Dec 2008, Alex Hunsaker wrote:
(dual core machine, --enable-debug, --enable-cassert build)
pgbench -c 2 -T60 -n -f test.sql
HEAD: tps = 9.674423
PATCH: tps = 9.695784
Two general suggestions here, not specific
On Mon, Dec 8, 2008 at 23:28, ITAGAKI Takahiro
[EMAIL PROTECTED] wrote:
Alex Hunsaker [EMAIL PROTECTED] wrote:
I was assigned to review this.
Thanks for your reviewing.
I assume that the basic concepts are ok and focus of discussion is in:
- New counters in struct Instrumentation
On Sun, Dec 7, 2008 at 19:13, Alex Hunsaker [EMAIL PROTECTED] wrote:
On Tue, Dec 2, 2008 at 02:35, ITAGAKI Takahiro
[EMAIL PROTECTED] wrote:
Here is an update version of contrib/pg_stat_statements.
Hello again!
I was assigned to review this.
... Some other things I accidentally left out
On Thu, Nov 12, 2009 at 11:56, Bernd Helmle maili...@oopsware.de wrote:
I've just started looking into this and wonder how this should look like.
IIRC another motivation for moving them into pg_constraint was we
could then give them names as required by the spec (unless I got mixed
up with
On Mon, Nov 16, 2009 at 11:45, Tom Lane t...@sss.pgh.pa.us wrote:
Alex Hunsaker bada...@gmail.com writes:
FYI defaults have the same problem. Would it be awkward would it be
to use pg_constraint for the book keeping as well? [ and by that I
really mean ALTER TABLE ADD CONSTRAINT my_default
While looking over the writable cte patch I noticed queries.sgml has
lots of things in the form literalFROM/. I tried various
googles to see if / is some kind of sgml/xml shorthand for close the
last opened tag. But alas, nothing found. Bad google foo?
Should we change those to be the right
On Mon, Nov 16, 2009 at 20:41, Tom Lane t...@sss.pgh.pa.us wrote:
Apparently --- it's perfectly legal in SGML. (I think not in XML.)
Cool. Thanks!
BTW anyone know how to escape and for google? I tried searching
for it-- but ran into a chick and egg situation. So the I tried
various forms
On Sun, Nov 15, 2009 at 14:27, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
I wrote:
Attached is the latest version of this patch.
Find attached a incremental diff with the following changes:
-get rid of operation argument to InitResultRelInfo, its unused now
-add some asserts to make
On Tue, Nov 17, 2009 at 03:54, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
Also, after reading through the previous threads; it was not
immediately obvious that you dealt with
http://archives.postgresql.org/pgsql-hackers/2009-10/msg00566.php by
only allowing selects or values at the
On Sat, Nov 21, 2009 at 16:07, David E. Wheeler da...@kineticode.com wrote:
On Nov 22, 2009, at 7:49 AM, Tom Lane wrote:
I'm thinking maybe we should remove -w. Comments?
Have you tried it on the existing tests to see what happens?
For me there I get:
*the breaking in create_cast
*various
Argh hit the wrong reply button...
-- Forwarded message --
From: Alex Hunsaker bada...@gmail.com
Date: Wed, Nov 25, 2009 at 10:20
Subject: Re: [HACKERS] Writeable CTE patch
To: Marko Tiikkaja marko.tiikk...@cs.helsinki.fi
On Mon, Nov 23, 2009 at 14:33, Marko Tiikkaja
On Sat, Nov 28, 2009 at 11:59, Tom Lane t...@sss.pgh.pa.us wrote:
1. I thought we'd agreed at
http://archives.postgresql.org/pgsql-hackers/2009-10/msg00558.php
that the patch should support WITH on DML statements, eg
with (some-query) insert into foo ...
This might not take much more
On Fri, Dec 18, 2009 at 10:57, Tom Lane t...@sss.pgh.pa.us wrote:
Obviously there's something there for the kernel guys to fix, but
even with a non-borked kernel it's an expensive thing to do.
Any thoughts on back patching this? While its not a bug per-say, it
seems reasonably low-risk. I for
On Thu, Jan 7, 2010 at 15:16, Tim Bunce tim.bu...@pobox.com wrote:
Is there any reason not to add .gitignore files into the repository?
They'll make no difference to those who don't use git, but be very
helpful to, and maintained by, those who do.
Since it seems we don't want them in CVS,
On Mon, Jan 4, 2010 at 09:55, Alvaro Herrera alvhe...@commandprompt.com wrote:
Magnus Hagander wrote:
Right. Which is why I like the idea of disabling the OOM killer for
the *postmaster*, but not the regular backends. Gives it a chance to
recover. It's not nice, but it's better than nothing.
On Thu, Jan 7, 2010 at 20:26, Tom Lane t...@sss.pgh.pa.us wrote:
Alex Hunsaker bada...@gmail.com writes:
We can either drop this in core (with a lot of #ifdef LINUX added)
Any thoughts on doing something like (in fork_process.c)
#ifdef LINUX
void oom_adjust()
{
...
}
#else
void oom_adjust
On Fri, Jan 8, 2010 at 07:53, Bruce Momjian br...@momjian.us wrote:
Alex Hunsaker wrote:
On Thu, Jan 7, 2010 at 20:26, Tom Lane t...@sss.pgh.pa.us wrote:
Alex Hunsaker bada...@gmail.com writes:
The usual solution for this kind of thing is:
#ifdef LINUX
#define OOM_ADJUST
On Fri, Jan 8, 2010 at 07:27, Tom Lane t...@sss.pgh.pa.us wrote:
Then, somebody who wants the feature would build with, say,
-DLINUX_OOM_ADJ=0
or another value if they want that.
Here is a stab at that.
It sets oom_adj for:
autovacuum workers
archivers (pgarch.c)
regular backends
On Fri, Jan 8, 2010 at 02:03, Magnus Hagander mag...@hagander.net wrote:
You can always create your own branch with just the .gitignore files
and merge that into whatever you're working on :)
The only thing annoying about that is if you generate diffs ala git
diff origin/master.. you get your
On Fri, Jan 8, 2010 at 10:07, Stephen Frost sfr...@snowman.net wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
I don't want to go to the trouble of creating (and documenting) a
configure option for this. Much less a GUC ;-)
Requiring a custom build to disable it would be horrible, in my view.
On Fri, Jan 8, 2010 at 10:24, Stephen Frost sfr...@snowman.net wrote:
As I recall, oom_adj wasn't visible in the container because you
explicitly set what proc entries processes can have access to when using
VServers, and OpenSSH didn't handle that cleanly. Guess what I'm just
saying is don't
On Fri, Jan 8, 2010 at 12:45, Tom Lane t...@sss.pgh.pa.us wrote:
Alex Hunsaker bada...@gmail.com writes:
Sure this was openssh? I just looked through the entire cvs history
for opensshp and found 0 references to 'oom' let alone 'oom_adj'.
Maybe something distro specific?
FWIW, I see
On Fri, Jan 8, 2010 at 15:24, Stephen Frost sfr...@snowman.net wrote:
There were a few issues, as it turns out, the particularly annoying one
was in the init script which caused upgrades to fail due to sshd not
being restarted, bug report here:
Thanks for the pointers!
On Sat, Jan 9, 2010 at 14:06, Peter Eisentraut pete...@gmx.net wrote:
I find this whole approach a bit evil.
I would tend to agree but this type of thing has been known since about 2004...
See http://thoughts.j-davis.com/2009/11/29/linux-oom-killer/,
particularly the comment from Greg Smith.
On Wed, Jan 13, 2010 at 12:54, Tom Lane t...@sss.pgh.pa.us wrote:
I'm a little worried by Stephen's plan, mainly because I'm concerned
that it would lead to ALTER TABLE taking exclusive lock on a table long
before it gets around to checking permissions. Still, that's just
extending a window
On Wed, Jan 13, 2010 at 13:46, Alex Hunsaker bada...@gmail.com wrote:
Im of the opinion if we are going to be meddling with the permission
checks [...]
Specifically:
http://archives.postgresql.org/pgsql-hackers/2009-05/msg00566.php
Sounds like most solutions would put us back to exactly what
On Thu, Jan 14, 2010 at 14:13, Dann Corbit dcor...@connx.com wrote:
How can I obtain the source code for pg_bulkload?
This is the wrong list, try
http://lists.pgfoundry.org/pipermail/pgbulkload-general/
That being said it seems to be right in the file list
On Sun, Jan 10, 2010 at 12:27, Robert Haas robertmh...@gmail.com wrote:
I am not very happy with ATPrepSetOptions(). I basically just
retained the logic from ATPrepSetDistinct(), but it doesn't really
make sense in this context. The idea that we want to support
attdistinct for system tables
On Sat, Jan 16, 2010 at 05:39, Robert Haas robertmh...@gmail.com wrote:
First, thanks for the review. Detailed comments/questions below.
On Fri, Jan 15, 2010 at 12:52 AM, Alex Hunsaker bada...@gmail.com wrote:
On Sun, Jan 10, 2010 at 12:27, Robert Haas robertmh...@gmail.com wrote:
I am
On Tue, Jan 19, 2010 at 07:49, Robert Haas robertmh...@gmail.com wrote:
That will mean that users can't use ALTER TABLE ... ALTER
COLUMN ... SET STATISTICS DISTINCT for system tables, but I don't
think that's much of a loss, and it certainly seems cleaner than
hoping that any additional
On Tue, Jan 19, 2010 at 13:06, Robert Haas robertmh...@gmail.com wrote:
On Fri, Jan 15, 2010 at 12:52 AM, Alex Hunsaker bada...@gmail.com wrote:
***
*** 152,158 CATALOG(pg_attribute,1249) BKI_BOOTSTRAP
BKI_WITHOUT_OIDS BKI_ROWTYPE_OID(75) BK
aclitem attacl[1
On Tue, Jan 19, 2010 at 23:02, Alex Hunsaker bada...@gmail.com wrote:
On Tue, Jan 19, 2010 at 13:06, Robert Haas robertmh...@gmail.com wrote:
On Fri, Jan 15, 2010 at 12:52 AM, Alex Hunsaker bada...@gmail.com wrote:
! text attoptions[1];
Unfortunately this change (which
On Wed, Jan 20, 2010 at 19:51, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jan 19, 2010 at 10:51 AM, Alex Hunsaker bada...@gmail.com wrote:
But yes, lets keep it simple for now.
OK. Updated patch attached. Changes:
- Incorporate your previous review patch.
- Omit attacl
On Thu, Jan 21, 2010 at 07:30, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jan 21, 2010 at 12:57 AM, Alex Hunsaker bada...@gmail.com wrote:
Seems to me a comment about the above might be nice. Something like
/* Things after here are should always be default null */ in
pg_attribute.h
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 think this is awesome! ]
Id vote for use warnings; as well.
-
On Sat, Jan 23, 2010 at 11:30, David E. Wheeler da...@kineticode.com wrote:
On Jan 22, 2010, at 7:59 PM, Alex Hunsaker wrote:
$name =~ s/::|'/_/g; # avoid package delimiters
+ $name =~ s/'/\'/g;
Looks to me like ' is already handled in the line above the one you added, no?
Well no, i
On Sat, Jan 23, 2010 at 12:42, David E. Wheeler da...@kineticode.com wrote:
On Jan 23, 2010, at 11:20 AM, Alex Hunsaker wrote:
Well no, i suppose we could fix that via:
$name =~ s/[:|']/_/g;
Im betting that was the intent.
Doubtful. In Perl, the package separator is either
On Sat, Jan 23, 2010 at 16:26, Andrew Dunstan and...@dunslane.net wrote:
Tim Bunce wrote:
- } keys %$imports;
+ } sort keys %$imports;
Ok, good.
- my $funcsrc;
- $funcsrc .= qq[ undef *{'$name'}; *{'$name'} = sub { $BEGIN $prolog
$src } ];
- #warn plperl mkfuncsrc:
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; as well.
I would to, but sadly it's not that simple.
warnings
On Fri, Jan 29, 2010 at 13:42, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
Bruce Momjian br...@momjian.us writes:
With the release of Postgres 9.0, should we consider changing the
default for 'standard_conforming_strings'?
I'm inclined to think we're going to have enough problems without
On Fri, Jan 29, 2010 at 14:03, Tom Lane t...@sss.pgh.pa.us wrote:
Alex Hunsaker bada...@gmail.com writes:
On Fri, Jan 29, 2010 at 13:42, Tom Lane t...@sss.pgh.pa.us wrote:
I stand by the position that it's way too late in the cycle for
insufficiently-thought-out proposals for major behavioral
On Mon, Jan 25, 2010 at 12:53, Tim Bunce tim.bu...@pobox.com wrote:
- Added the 'warnings' pragma to the list of modules to load into Safe.
So plperl functions can now use warnings; - added test for that.
*yay*
- Added 'use 5.008001;' to plc_perlboot.pl as a run-time check to
complement
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:
A couple of comments. *note* I have not tested this as a whole yet
(due to rejects).
in plc_perboot.pl
+$funcsrc .= qq[ package main; undef *{'$name'}; *{'$name
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.
- Ensure Safe container opmask is restored even if @EvalInSafe
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 the changes from HEAD up through my
chain of branches.
Can you send
On Sat, Jan 30, 2010 at 08:49, Tim Bunce tim.bu...@pobox.com wrote:
This is an update the fourth of the patches to be split out from the
former 'plperl feature patch 1'.
Changes in this patch:
- Adds plperl.on_trusted_init and plperl.on_untrusted_init GUCs
on_trusted_init is PGC_USERSET,
On Tue, Feb 2, 2010 at 20:46, Robert Haas robertmh...@gmail.com wrote:
On Tue, Feb 2, 2010 at 10:46 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Feb 2, 2010 at 10:42 PM, Alex Hunsaker bada...@gmail.com wrote:
On Sat, Jan 30, 2010 at 08:49, Tim Bunce tim.bu...@pobox.com wrote
On Tue, Feb 2, 2010 at 21:38, Tom Lane t...@sss.pgh.pa.us wrote:
Alex Hunsaker bada...@gmail.com writes:
Yeah the both is gross. How about:
plperl.on_plperl_init
plperl.on_plperlu_init
plperl.on_init ?
I like the first two. The problem of selecting a good name for the
third one is easily
On Tue, Feb 2, 2010 at 22:50, Tom Lane t...@sss.pgh.pa.us wrote:
Alex Hunsaker bada...@gmail.com writes:
On Tue, Feb 2, 2010 at 21:38, Tom Lane t...@sss.pgh.pa.us wrote:
Alex Hunsaker bada...@gmail.com writes:
Yeah the both is gross. How about:
plperl.on_plperl_init
plperl.on_plperlu_init
On Wed, Feb 3, 2010 at 00:46, Alex Hunsaker bada...@gmail.com wrote:
On Tue, Feb 2, 2010 at 22:50, Tom Lane t...@sss.pgh.pa.us wrote:
Alex Hunsaker bada...@gmail.com writes:
On Tue, Feb 2, 2010 at 21:38, Tom Lane t...@sss.pgh.pa.us wrote:
Alex Hunsaker bada...@gmail.com writes:
Yeah the both
On Wed, Feb 3, 2010 at 06:41, Andrew Dunstan and...@dunslane.net wrote:
Alex Hunsaker wrote:
Well its already in.
Well *that's* easily fixed. I think it's a bad idea, because it's
unclear what you should put there and what the security implications
are.
I can't speak for its virtue
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 are not available when the code is run.
Hrm, we might want to stick why
On Wed, Feb 3, 2010 at 10:18, Alex Hunsaker bada...@gmail.com 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:
If we're going to bikeshed the names, I'd suggest:
plperl.on_init - run
On Wed, Feb 3, 2010 at 10:56, Tim Bunce tim.bu...@pobox.com wrote:
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
On Wed, Feb 3, 2010 at 11:28, Tom Lane t...@sss.pgh.pa.us wrote:
Tim Bunce tim.bu...@pobox.com writes:
I do see a need for a GRANT check and I'm adding one now (based on
the code in CreateFunction() in functioncmds.c - thanks to RhodiumToad
on IRC for the pointer).
What exactly are you
On Wed, Feb 3, 2010 at 11:43, Alex Hunsaker bada...@gmail.com wrote:
On Wed, Feb 3, 2010 at 11:28, Tom Lane t...@sss.pgh.pa.us wrote:
Tim Bunce tim.bu...@pobox.com writes:
I do see a need for a GRANT check and I'm adding one now (based on
the code in CreateFunction() in functioncmds.c - thanks
On Wed, Feb 3, 2010 at 12:04, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net writes:
%_SHARED has been around for several years now, and if there are genuine
security concerns about it ISTM they would apply today, regardless of
these patches.
Yes. I am not at all
On Fri, Feb 5, 2010 at 06:40, Tim Bunce tim.bu...@pobox.com 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 are PGC_SUSET
On Fri, Feb 12, 2010 at 13:42, Andrew Dunstan and...@dunslane.net wrote:
Alex Hunsaker wrote:
in plc_safe_ok.pl
+use vars qw($PLContainer $SafeClass @EvalInSafe @ShareIntoSafe);
...the *_init gucs to be able to stick things into
@ShareIntoSafe and friends?
I'm not sure it's fine with me
On Fri, Feb 12, 2010 at 17:57, Andrew Dunstan and...@dunslane.net wrote:
Another objection is that discussion on this facility has been pretty scant.
I think that's putting it mildly.
Well I can certainly attest to that seeing as how I spotted it purely
by review...
--
Sent via pgsql-hackers
On Fri, Feb 12, 2010 at 17:57, Andrew Dunstan and...@dunslane.net wrote:
r
Alex Hunsaker wrote:
Yes it could allow people who
can set the plperl.*_init functions to muck with the safe.
It's quite easy to subvert Safe.pm today, sadly. ...
If anything that sounds like an argument
On Fri, Feb 12, 2010 at 19:14, Robert Haas robertmh...@gmail.com wrote:
Sounds like it would considerably simplify
the patch, too.
I overstated that. The way its done now we could just change the
decelerations to 'my' and drop an if block. Id be in favor of more or
less keeping the internals
On Wed, Feb 24, 2010 at 14:35, Richard Huxton d...@archonet.com wrote:
With plperl.on_init allowing the loading of modules, might there be some
merit (and little cost) in allowing the same style of function-mapping as
with C functions?
CREATE FUNCTION add_one(integer) RETURNS integer
AS
On Thu, Feb 25, 2010 at 20:40, Tom Lane t...@sss.pgh.pa.us wrote:
It's not going to be easier to implement. Yeah, it would be easy to
provide a global switch via a GUC setting, but that's not going to be
helpful, because this is the sort of thing that really needs to be
managed per-query.
On Thu, Feb 25, 2010 at 21:28, Alex Hunsaker bada...@gmail.com wrote:
Not to mention you can already do this more or less client side with a
nice driver.
[ uninformed noise ... ]
I did seem to miss the part where everyone thinks this is a crock...
But I don't remember seeing numbers on parse
On Thu, Feb 25, 2010 at 22:11, Tom Lane t...@sss.pgh.pa.us wrote:
Alex Hunsaker bada...@gmail.com writes:
Uh, no, this isn't about saving either parse time or bandwidth.
The discussion is about when to expend more planning time in hopes
of getting better plans.
This is what im tripping over
On Fri, Feb 26, 2010 at 08:07, Tom Lane t...@sss.pgh.pa.us wrote:
Alex Hunsaker bada...@gmail.com writes:
Let me see if I can sum up what I was trying to say:
[ this can be solved by using or avoiding prepared statements ]
Not really. The place where that argument really fails is inside
On Fri, Feb 26, 2010 at 09:50, Robert Haas robertmh...@gmail.com wrote:
On Fri, Feb 26, 2010 at 1:29 AM, Alex Hunsaker bada...@gmail.com wrote:
Prepared plans + exec plan (new guc/ protocol thing):
Use: not quite sure
Problems: slow because it would replan every time
Solutions: use
On Mon, Mar 8, 2010 at 09:03, Tom Lane t...@sss.pgh.pa.us wrote:
Tim Bunce tim.bu...@pobox.com writes:
3. requires Safe 2.25 (which has assorted fixes, including security).
#3 is still an absolute nonstarter, especially for a patch that we'd
wish to backpatch.
FWIW I think its a given you
On Mon, Mar 8, 2010 at 10:14, Tom Lane t...@sss.pgh.pa.us wrote:
David E. Wheeler da...@kineticode.com writes:
On Mar 8, 2010, at 8:03 AM, Tom Lane wrote:
#3 is still an absolute nonstarter, especially for a patch that we'd
wish to backpatch.
You're at least going to want to exclude Safe
On Thu, Mar 18, 2010 at 15:07, Jeff Davis pg...@j-davis.com wrote:
On Thu, 2010-03-18 at 16:50 -0400, Tom Lane wrote:
The VM is (a) not compressed and (b) not correctness-critical.
Wrong bit values don't do any serious damage.
The VM cause wrong results if a bit is set that's not supposed to
On Mon, Mar 29, 2010 at 12:17, Simon Riggs si...@2ndquadrant.com wrote:
You're not addressing the original point. I have been asked how would
users know which tables have been removed and whether there is a way of
checking that.
Uhh... they wont be in the explain output... Seems simple
On Mon, Mar 29, 2010 at 13:41, Simon Riggs si...@2ndquadrant.com wrote:
Uhh... they wont be in the explain output... Seems simple enough.
That is exactly what I replied, though nobody felt that was a great
answer.
Maybe I missed it, but why exactly do they care? About the only
reason I can
1 - 100 of 338 matches
Mail list logo
