On Mon, 28 Jan 2008, Jeff Davis wrote:
I think that pg_dump is a reasonable use case for synchoronized scans
when the table has not been clustered. It could potentially make pg_dump
have much less of a performance impact when run against an active
system.
One of the advantages I see with ma
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 datab
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
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)
"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 h
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?
>
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 t
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
> 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
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:
> 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 P
-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'
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, wa
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 a
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
G
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
"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 t
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
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, 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
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
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
> deo
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 plpe
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
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
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
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.
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_ON
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 o
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 p
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 | pho
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
> > miss
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 debugger)
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 d
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!
http://www.sear
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
38 matches
Mail list logo
