Guillaume Smet wrote:
Hi Russell,
On Jan 28, 2008 7:27 AM, Russell Smith [EMAIL PROTECTED] wrote:
Can somebody explain why it's important to load with
synchronized_scanning off?
do_sql_command(g_conn, SET synchronized_scanning TO off);
It's the start point of this patch. See this
On Sat, 2008-01-26 at 14:27 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Fri, 2008-01-25 at 19:02 -0500, Tom Lane wrote:
This seems large, complex, and untested (I note in particular a
guaranteed-to-fail Assert).
Yes, its for discussion. How would you describe such
This is the patch allows logging of the explain plan for each query run, as
described here:
http://archives.postgresql.org/pgsql-performance/2008-01/msg00245.php
I hope this is useful.
Dean.
_
Telly addicts unite!
I am not seeing my mail getting listed in the archives. So i am just
resending it, in case the above one has got missed.
Thanks,
Gokul.
On Jan 28, 2008 4:14 PM, Gokulakannan Somasundaram [EMAIL PROTECTED]
wrote:
Doh! Can you please send another patch with gram.y as well. Mine is
missing
On Jan 28, 2008 12:51 PM, Pavel Stehule [EMAIL PROTECTED] wrote:
Hello
this patch define new function flag - OBFUSCATE. With this flag
encrypted source code is stored to probin column. Password is stored
in GUC_SUPERUSER_ONLY item - it is similar security like SQL Server
does (where
On Jan 28, 2008 8:21 AM, Gokulakannan Somasundaram [EMAIL PROTECTED] wrote:
I am not seeing my mail getting listed in the archives. So i am just
resending it, in case the above one has got missed.
It was sent. Archive processing is delayed.
--
Jonah H. Harris, Sr. Software Architect | phone:
On 28/01/2008, Dave Page [EMAIL PROTECTED] wrote:
On Jan 28, 2008 2:26 PM, Pavel Stehule [EMAIL PROTECTED] wrote:
sure, but do you know, Tom dislikes new columns in pg_proc :).
Tom doesn't seem to like the idea of obfuscation of function code much
either :-)
This
patch is usable sample
On 28/01/2008, Gregory Stark [EMAIL PROTECTED] wrote:
Someone along the way suggested doing this as a kind of wrapper PL language.
So you would have a PL language like obfuscate:plperl which would obfuscate
the source code on the way in. Then when you execute a function it would
deobfuscate
On Jan 28, 2008 2:26 PM, Pavel Stehule [EMAIL PROTECTED] wrote:
sure, but do you know, Tom dislikes new columns in pg_proc :).
Tom doesn't seem to like the idea of obfuscation of function code much
either :-)
This
patch is usable sample of one possible solution and doesn't need
initdb. And
On 28/01/2008, Dave Page [EMAIL PROTECTED] wrote:
On Jan 28, 2008 12:51 PM, Pavel Stehule [EMAIL PROTECTED] wrote:
Hello
this patch define new function flag - OBFUSCATE. With this flag
encrypted source code is stored to probin column. Password is stored
in GUC_SUPERUSER_ONLY item - it
On Mon, Jan 28, 2008 at 09:21:50AM +, Dean Rasheed wrote:
This is the patch allows logging of the explain plan for each query run, as
described here:
http://archives.postgresql.org/pgsql-performance/2008-01/msg00245.php
I hope this is useful.
Dean.
Dean,
Maybe I missed
Pavel Stehule [EMAIL PROTECTED] writes:
In such a scheme I think you would put the key in an attribute of the
language. Either in pg_lang or some configuration location which the
obfuscate:plperl interpreter knows where to find.
what is advantage?
It wouldn't require any core changes. It
Pavel Stehule wrote:
Hello
this patch define new function flag - OBFUSCATE. With this flag
encrypted source code is stored to probin column. Password is stored
in GUC_SUPERUSER_ONLY item - it is similar security like SQL Server
does (where privileged users can access system tables with source
Pavel Stehule [EMAIL PROTECTED] writes:
Do you thing some binary module that load some encrypted sources from
files? It can be possible too. But if source code will be stored in
pg_proc, then we need third method. Some like obfuscate (prev. are
validate and call), because we can't to store
Someone along the way suggested doing this as a kind of wrapper PL language.
So you would have a PL language like obfuscate:plperl which would obfuscate
the source code on the way in. Then when you execute a function it would
deobfuscate the source code and then just pass it to the normal plperl.
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Uh, imagine:
test= SELECT * from pg_class
test- help
Technically 'help' is now an alias for 'pg_class'. Are you suggesting
supporting 'help' in this usage? People were saying they forget
semicolons, so this 'help' usage is
On Tue, Dec 11, 2007 at 08:58:05AM -0500, Andrew Dunstan wrote:
I'm actually inclined to vote with Stephen that this is a silly change.
I just put up the patch to show the best way of doing it if we're gonna
do it ...
OK. I'm not going to die in a ditch over it.
On the other hand, warning
On Wed, Dec 05, 2007 at 06:49:00PM +0100, Guillaume Smet wrote:
On Dec 5, 2007 3:26 PM, Greg Sabino Mullane [EMAIL PROTECTED] wrote:
Agreed, this would be a nice 8.4 thing. But what about 8.3 and 8.2? Is
there a reason not to make this change? I know I've been lazy and not run
any absolute
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Maybe a better TODO would be to do this task in the way that has
previously been suggested:
http://archives.postgresql.org/pgsql-hackers/2007-08/msg00258.php
I'm certainly not happy about any proposal to put a password/key in a
Andrew Dunstan [EMAIL PROTECTED] writes:
Maybe a better TODO would be to do this task in the way that has
previously been suggested:
http://archives.postgresql.org/pgsql-hackers/2007-08/msg00258.php
I'm certainly not happy about any proposal to put a password/key in a
GUC var - that
On 28/01/2008, Andrew Dunstan [EMAIL PROTECTED] wrote:
Pavel Stehule wrote:
Hello
this patch define new function flag - OBFUSCATE. With this flag
encrypted source code is stored to probin column. Password is stored
in GUC_SUPERUSER_ONLY item - it is similar security like SQL Server
Gregory Stark [EMAIL PROTECTED] writes:
There is a validator function which gets called when you create a
function but I don't think it has any opportunity to substitute its
result for the original in prosrc.
It would have to do a heap_update on the prosrc row, but that doesn't
seem like a
Dean,
Maybe I missed something obvious here, but how does this patch handle
the situation where people have turned on INTEGER_DATETIMES?
Cheers,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: [EMAIL PROTECTED]
On Mon, Jan 28, 2008 at 08:49:23PM +, Dean Rasheed wrote:
On Mon, Jan 28, 2008 at 07:55:53PM +, Dean Rasheed wrote:
Dean,
Maybe I missed something obvious here, but how does this patch handle
the situation where people have turned on INTEGER_DATETIMES?
Cheers,
David.
Tom Lane [EMAIL PROTECTED] writes:
My recollection is that certain cryptography laws make hooks for crypto
just as problematic as actual crypto code. We'd have to tread very
carefully --- general purpose hooks are OK but anything narrowly
tailored to encryption purposes would be a hazard.
Date: Mon, 28 Jan 2008 12:08:00 -0800
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
CC: pgsql-patches@postgresql.org
Subject: Re: [PATCHES] Auto-explain patch
On Mon, Jan 28, 2008 at 07:55:53PM +, Dean Rasheed wrote:
Dean,
Maybe I missed something obvious here, but how does this
On 28/01/2008, Tom Lane [EMAIL PROTECTED] wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Maybe a better TODO would be to do this task in the way that has
previously been suggested:
http://archives.postgresql.org/pgsql-hackers/2007-08/msg00258.php
I'm certainly not happy about any
On 28/01/2008, Gregory Stark [EMAIL PROTECTED] wrote:
Pavel Stehule [EMAIL PROTECTED] writes:
In such a scheme I think you would put the key in an attribute of the
language. Either in pg_lang or some configuration location which the
obfuscate:plperl interpreter knows where to find.
Neil Conway wrote:
On Sun, 2008-01-27 at 12:36 -0500, Tom Lane wrote:
Both of the above arguments hold water only if we implement
compatible *semantics*, not merely syntax, so I find them
unconvincing at this stage.
How are the semantics of the proposed patch incompatible with the SQL
spec
Hello
this patch define new function flag - OBFUSCATE. With this flag
encrypted source code is stored to probin column. Password is stored
in GUC_SUPERUSER_ONLY item - it is similar security like SQL Server
does (where privileged users can access system tables with source code
or can use
On 28/01/2008, Gregory Stark [EMAIL PROTECTED] wrote:
Pavel Stehule [EMAIL PROTECTED] writes:
Do you thing some binary module that load some encrypted sources from
files? It can be possible too. But if source code will be stored in
pg_proc, then we need third method. Some like obfuscate
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
However, I definitely agree that a separate loadable PL is the way to go
for functionality of this sort. There is no way that a dependency on
pgcrypto is going to be accepted into core, not even in the (ahem)
obfuscated way that it's
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
However, I definitely agree that a separate loadable PL is the way to go
for functionality of this sort. There is no way that a dependency on
pgcrypto is going to be accepted into core, not even in the (ahem)
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Greg Sabino Mullane wrote:
-- Start of PGP signed section.
Why not run help when someone enters help (or HELP ME!)
On Mon, Jan 28, 2008 at 07:55:53PM +, Dean Rasheed wrote:
Dean,
Maybe I missed something obvious here, but how does this patch handle
the situation where people have turned on INTEGER_DATETIMES?
Cheers,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
On Sun, 2008-01-27 at 15:07 -0500, Tom Lane wrote:
Per today's -hackers discussion, add a GUC variable to allow clients to
disable the new synchronized-scanning behavior, and make pg_dump disable
sync scans so that it will reliably preserve row ordering. This is a
pretty trivial patch, but
Andrew Dunstan [EMAIL PROTECTED] writes:
using this example, it seems to me that if we dump the encrypted/encoded
source and restore into another database with a different encoding, the
decoded/decrypted source will still be in the old database encoding,
i.e. not valid in the new database
37 matches
Mail list logo
