On Dec 21, 2007 12:40 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Merlin Moncure" <[EMAIL PROTECTED]> writes:
> > On Dec 20, 2007 6:01 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> >> So if you want something other than endless arguments to happen,
> >> come up with a nice key-management design for encr
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> On Dec 20, 2007 6:01 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
>> So if you want something other than endless arguments to happen,
>> come up with a nice key-management design for encrypted function
>> bodies.
> Maybe a key management solution isn't req
On Dec 20, 2007 6:01 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Merlin Moncure" <[EMAIL PROTECTED]> writes:
> > I don't really agree that wrapping pl/pgsql with encryptor/decryptor
> > is a bad idea.
>
> So if you want something other than endless arguments to happen,
> come up with a nice key-mana
>
> wrapping pl/pgsql with encryptor/decryptor
>
> It's quite a good idea, because it has more than zero chance of
> succeeding politically in the community.
>
It's additionally a good idea because the other big database is using the
same approach. Easier sell to phb.
Harald
--
GHUM Harald Mass
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> I don't really agree that wrapping pl/pgsql with encryptor/decryptor
> is a bad idea.
It's quite a good idea, because it has more than zero chance of
succeeding politically in the community.
The fundamental reason why preventing access to pg_proc.pro
On Dec 20, 2007 5:28 PM, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> > I don't really agree that wrapping pl/pgsql with encryptor/decryptor
> > is a bad idea.
>
> Right. But do you agree that it is separate from having hidden prosrc?
> If we can complete a design then let's shot that way, and aim
On Thu, 20 Dec 2007, Roberts, Jon wrote:
I still say this I a needed feature if you want adoption for enterprise
level databases in larger companies.
It is to some people, and Joshua's opinion is, like everybody else's, just
one person's view on what's important.
The security out of the box
On Thu, Dec 20, 2007 at 05:04:33PM -0500, Merlin Moncure wrote:
> right, right, thanks for the lecture. I am aware of various issues
> with key management.
Sorry to come off that way. It wasn't my intention to lecture, but rather
to try to stop dead a cure that, in my opinion, is rather worse th
Merlin Moncure escribió:
> I don't really agree that wrapping pl/pgsql with encryptor/decryptor
> is a bad idea.
Right. But do you agree that it is separate from having hidden prosrc?
If we can complete a design then let's shot that way, and aim at
encryption sometime in the future :-)
I have t
On Dec 20, 2007 4:06 PM, S Golly <[EMAIL PROTECTED]> wrote:
> The server is running 8.2.5 FreeBSD 6.1 with 3 GB of RAM.
> I have a table with over 100M rows. I have a unique index (primary key) on
> column name called aid.
> The select count(aid) .. does a Bitmap heap scan when the right side
> con
The server is running 8.2.5 FreeBSD 6.1 with 3 GB of RAM.
I have a table with over 100M rows. I have a unique index (primary key) on
column name called aid.
The select count(aid) .. does a Bitmap heap scan when the right side
condition is above 100,000,000 (if i take one zero off it does a pure ind
On Dec 20, 2007 3:52 PM, Andrew Sullivan <[EMAIL PROTECTED]> wrote:
> On Thu, Dec 20, 2007 at 03:35:42PM -0500, Merlin Moncure wrote:
> >
> > Key management is an issue but easily solved. Uber simple solution is
> > to create a designated table holding the key(s) and use classic
> > permissions to
On Thu, Dec 20, 2007 at 03:24:34PM -0600, Roberts, Jon wrote:
>
> Actually, PostgreSQL already has column level security for pg_stat_activity.
Not exactly. pg_stat_activity is a view.
But I think someone suggested upthread experimenting with making pg_proc
into a view, and making the real tab
> -Original Message-
> From: Andrew Sullivan [mailto:[EMAIL PROTECTED]
> Sent: Thursday, December 20, 2007 3:04 PM
> To: pgsql-performance@postgresql.org
> Subject: Re: [PERFORM] viewing source code
>
> On Thu, Dec 20, 2007 at 01:45:08PM -0600, Roberts, Jon wrote:
> > Businesses use data
[EMAIL PROTECTED] ("Roberts, Jon") writes:
> I think it is foolish to not make PostgreSQL as feature rich when it
> comes to security as the competition because you are idealistic when
> it comes to the concept of source code. PostgreSQL is better in
> many ways to MS SQL Server and equal to many
On Thu, Dec 20, 2007 at 01:45:08PM -0600, Roberts, Jon wrote:
> Businesses use databases like crazy. Non-technical people write their own
> code to analyze data. The stuff they write many times is as valuable as the
> data itself and should be protected like the data. They don't need or want
> m
On Thu, Dec 20, 2007 at 03:35:42PM -0500, Merlin Moncure wrote:
>
> Key management is an issue but easily solved. Uber simple solution is
> to create a designated table holding the key(s) and use classic
> permissions to guard it.
Any security expert worth the title would point and laugh at th
On Dec 20, 2007 3:07 PM, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> I don't think that makes any kind of sense. Hiding prosrc should happen
> on a entirely different level from the language on which the function is
> written. It's a completely orthogonal decision. Besides, you probably
> don't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 20 Dec 2007 14:02:57 -0600
"Roberts, Jon" <[EMAIL PROTECTED]> wrote:
> I'm tired of arguing. You win. I still say this I a needed feature
> if you want adoption for enterprise level databases in larger
> companies. The security out of the
Joshua D. Drake escribió:
> I don't know that it needs to be that extensive. I noted elsewhere in
> the thread the idea of a plpgsql_s. I think that is an interesting
> idea. I just don't think it needs to be incorporated into
> postgresql-core.
I don't think that makes any kind of sense. Hidin
> -Original Message-
> From: Joshua D. Drake [mailto:[EMAIL PROTECTED]
> Sent: Thursday, December 20, 2007 1:54 PM
> To: Roberts, Jon
> Cc: 'Trevor Talbot'; Kris Jurka; Merlin Moncure; Jonah H. Harris; Bill
> Moran; pgsql-performance@postgresql.org
> Subject: Re: [PERFORM] viewing source
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 20 Dec 2007 13:45:08 -0600
"Roberts, Jon" <[EMAIL PROTECTED]> wrote:
> I think it is foolish to not make PostgreSQL as feature rich when it
> comes to security as the competition because you are idealistic when
> it comes to the concept of sou
> -Original Message-
> From: Joshua D. Drake [mailto:[EMAIL PROTECTED]
> Sent: Thursday, December 20, 2007 10:40 AM
> To: Roberts, Jon
> Cc: 'Trevor Talbot'; Kris Jurka; Merlin Moncure; Jonah H. Harris; Bill
> Moran; pgsql-performance@postgresql.org
> Subject: Re: [PERFORM] viewing source
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 20 Dec 2007 10:47:53 -0800
"Trevor Talbot" <[EMAIL PROTECTED]> wrote:
>
> > This "feature" as it is called can be developed externally and has
> > zero reason to exist within PostgreSQL. If the feature has the
> > level of demand that people
On 12/20/07, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
> Roberts, Jon wrote:
> > This really is a needed feature to make PostgreSQL more attractive to
> > businesses. A more robust security model that better follows commercial
> > products is needed for adoption.
> I would argue that commercial
Roberts, Jon escribió:
> So your suggestion is first to come up with a query that dynamically checks
> permissions and create a view for it. Secondly, change pgAdmin to reference
> this view in place of pg_proc. Actually, it should be extended to all
> objects in the database, not just pg_proc.
On Dec 20, 2007 12:39 PM, A.M. <[EMAIL PROTECTED]> wrote:
> On Dec 20, 2007, at 11:30 AM, Roberts, Jon wrote:
> >> On Dec 20, 2007 9:07 AM, Roberts, Jon <[EMAIL PROTECTED]>
> >> wrote:
> >>> So your suggestion is first to come up with a query that dynamically
> >> checks
> >>> permissions and creat
On Dec 20, 2007 11:30 AM, Roberts, Jon <[EMAIL PROTECTED]> wrote:
> > -Original Message-
> > From: Merlin Moncure [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, December 20, 2007 8:30 AM
> > To: Roberts, Jon
> > Cc: Alvaro Herrera; Trevor Talbot; Joshua D. Drake; Kris Jurka; Jonah H.
> > Har
On Dec 20, 2007, at 11:30 AM, Roberts, Jon wrote:
-Original Message-
From: Merlin Moncure [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 20, 2007 8:30 AM
To: Roberts, Jon
Cc: Alvaro Herrera; Trevor Talbot; Joshua D. Drake; Kris Jurka;
Jonah H.
Harris; Bill Moran; pgsql-perform
Roberts, Jon wrote:
This really is a needed feature to make PostgreSQL more attractive to
businesses. A more robust security model that better follows commercial
products is needed for adoption.
I would argue that commercial products need to get a clue and stop
playing bondage with their u
> -Original Message-
> From: Merlin Moncure [mailto:[EMAIL PROTECTED]
> Sent: Thursday, December 20, 2007 8:30 AM
> To: Roberts, Jon
> Cc: Alvaro Herrera; Trevor Talbot; Joshua D. Drake; Kris Jurka; Jonah H.
> Harris; Bill Moran; pgsql-performance@postgresql.org
> Subject: Re: [PERFORM] v
On 20/12/2007, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Anton Melser escribió:
> > Hi,
> > Sorry but I couldn't find the answer to this...
> >
> > I would like to empty all stats (pg_stat_all_tables probably mostly)
> > so I can get an idea of what's going on now. Is this possible? I
> > didn't
On Dec 20, 2007 9:07 AM, Roberts, Jon <[EMAIL PROTECTED]> wrote:
> So your suggestion is first to come up with a query that dynamically checks
> permissions and create a view for it. Secondly, change pgAdmin to reference
> this view in place of pg_proc. Actually, it should be extended to all
Thi
So your suggestion is first to come up with a query that dynamically checks
permissions and create a view for it. Secondly, change pgAdmin to reference
this view in place of pg_proc. Actually, it should be extended to all
objects in the database, not just pg_proc. If you don't have this
dictiona
On 12/20/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Scott Marlowe" <[EMAIL PROTECTED]> writes:
> > Well, I'm not even sure if those got applied or were just Tom hacking
> > in the basement or, heck, my fevered imagination. :)
>
> For the record, I hack in the attic ... or what I tell the IRS is my
Anton Melser escribió:
> Hi,
> Sorry but I couldn't find the answer to this...
>
> I would like to empty all stats (pg_stat_all_tables probably mostly)
> so I can get an idea of what's going on now. Is this possible? I
> didn't want to just go deleting without knowing what it would do...
Sure, us
Le jeudi 20 décembre 2007, Decibel! a écrit :
> A work-around others have used is to have the trigger just insert
> into a 'staging' table and then periodically take the records from
> that table and summarize them somewhere else.
And you can even use the PgQ skytools implementation to easily have
Hi,
Sorry but I couldn't find the answer to this...
I would like to empty all stats (pg_stat_all_tables probably mostly)
so I can get an idea of what's going on now. Is this possible? I
didn't want to just go deleting without knowing what it would do...
Thanks
Anton
--
echo '16i[q]sa[ln0=aln100%
38 matches
Mail list logo
