Re: [HACKERS] Prepared statements considered harmful

On Thu, Aug 31, 2006 at 08:06:57PM +0700, Jeroen T. Vermeulen wrote: > On Thu, August 31, 2006 18:56, Peter Eisentraut wrote: > > > With time, it becomes ever clearer to me that prepared SQL > > statements are just a really bad idea. On some days, it seems like > > half the performance problems i

Re: [HACKERS] tsvector/tsearch equality and/or portability issue

On Thu, Aug 24, 2006 at 09:40:13PM +0400, Teodor Sigaev wrote: > >devel=# select 'blah foo bar'::tsvector = 'blah foo bar'::tsvector; > > ?column? > >-- > > f > >(1 row) > > Fixed in 8.1 and HEAD. Thank you Things still seem to be broken for me. Among other things, the script at

Re: [HACKERS] lastval exposes information that currval does not

On Fri, Jul 28, 2006 at 09:54:38PM +0200, Martijn van Oosterhout wrote: > Not the least of which is that arguments involving "people can install > C code into the backend and break security" are truisms: installed C > code can do *anything* which is why only superusers can install such > functions.

Re: [HACKERS] lastval exposes information that currval does not

On Thu, Jul 27, 2006 at 05:01:37PM -0400, Andrew Dunstan wrote: > Tom Lane wrote: > > >Alvaro Herrera <[EMAIL PROTECTED]> writes: > >>What we should really do is have lastval() fail if the user does not > >>have appropiate permissions on the schema. Having it not fail is a bug, > >>and documentin

Re: [HACKERS] lastval exposes information that currval does not

On Thu, Jul 27, 2006 at 04:40:45PM -0400, Tom Lane wrote: > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > What we should really do is have lastval() fail if the user does not > > have appropiate permissions on the schema. Having it not fail is a bug, > > and documenting a bug turns it not into a

Re: [HACKERS] lastval exposes information that currval does not

On Thu, Jul 27, 2006 at 06:36:30PM +0200, Peter Eisentraut wrote: > I'm sure some people agree that there is a problem. It would help, > however, if you were not talking about two different things at once. > And it would help if you actually proposed a change that would improve > matters. What

Re: [HACKERS] lastval exposes information that currval does not

All right, I give up. I guess no one seems to want to admit this is a bad security policy, or accurately document it. Does that make it an easter egg? On Thu, Jul 20, 2006 at 01:59:43PM -0400, Bruce Momjian wrote: > > OK, text again updated: > >For schemas, allows access to objects conta

Re: [HACKERS] lastval exposes information that currval does not

On Wed, Jul 19, 2006 at 02:42:49PM -0400, Bruce Momjian wrote: > Updated text: > >For schemas, allows access to objects contained in the specified >schema (assuming that the objects' own privilege requirements are >also met). Essentially this allows the grantee to look up

Re: [HACKERS] lastval exposes information that currval does not

On Wed, Jul 12, 2006 at 06:09:31PM -0400, Bruce Momjian wrote: > Phil Frost wrote: > > On Wed, Jul 12, 2006 at 11:37:37AM -0400, Bruce Momjian wrote: > > > > > > Updated text: > > > > > >For schemas, allows access to objects contained in the

Re: [HACKERS] set search_path in dump output considered harmful

On Thu, Jul 13, 2006 at 07:17:31PM -0400, Tom Lane wrote: > Phil Frost <[EMAIL PROTECTED]> writes: > > I've recently migrated one of my databases to using veil. This involved > > creating a 'private' schema and moving all tables to it. > > ... > >

[HACKERS] feature request: pg_dump --view

I could really use a --view option to pg_dump (and pg_restore, i imagine). This would instruct pg_dump to dump just a named view, much like --table, --trigger, --function, etc. Could this maybe be added to a todo list? ---(end of broadcast)--- TIP 9:

Re: [HACKERS] lastval exposes information that currval does not

On Wed, Jul 12, 2006 at 11:37:37AM -0400, Bruce Momjian wrote: > > Updated text: > >For schemas, allows access to objects contained in the specified >schema (assuming that the objects' own privilege requirements are >also met). Essentially this allows the grantee to look

Re: [HACKERS] lastval exposes information that currval does not

On Mon, Jul 10, 2006 at 08:24:08PM +0200, Martijn van Oosterhout wrote: > On Mon, Jul 10, 2006 at 01:42:27PM -0400, Phil Frost wrote: > > I think that misses the point. One can easily find objects in a schema > > without usage by examining the system catalogs. The point is that the

Re: [HACKERS] lastval exposes information that currval does not

On Mon, Jul 10, 2006 at 12:49:54PM -0400, Bruce Momjian wrote: > > Docs updated: > > >For schemas, allows the grantee to find objects contained in the >specified schema (assuming that the objects' own privilege requirements >are also met). > I think that mis

Re: [HACKERS] lastval exposes information that currval does not

On Sun, Jul 09, 2006 at 02:32:24PM +0200, Martijn van Oosterhout wrote: > On Sat, Jul 08, 2006 at 05:47:33PM -0400, Jim Nasby wrote: > > On Jul 6, 2006, at 11:02 AM, Phil Frost wrote: > > >I hope the above example is strong enough to elicit a comment from a > > >qualif

Re: [HACKERS] lastval exposes information that currval does not

On Wed, Jul 05, 2006 at 05:57:08PM -0700, Joshua D. Drake wrote: > > > I am well aware of what security definer means. The significant part of > > this example is that lastval() will allow the caller to see the value of > > a sequence where currval('seq') will not. This means that things which > >

Re: [HACKERS] lastval exposes information that currval does not

On Wed, Jul 05, 2006 at 08:06:12PM -0400, Chris Campbell wrote: > On Jul 5, 2006, at 14:51, Phil Frost wrote: > > >test=# create function bump() returns bigint language sql security > >definer as $$ select nextval('private.seq'); $$; > > SECURITY DEFINER mea

[HACKERS] lastval exposes information that currval does not

test=# create schema private; CREATE SCHEMA test=# create sequence private.seq; CREATE SEQUENCE test=# create function bump() returns bigint language sql security definer as $$ select nextval('private.seq'); $$; CREATE FUNCTION test=# revoke usage on schema private from pfrost; REVOKE test=# grant

[HACKERS] set search_path in dump output considered harmful

I've recently migrated one of my databases to using veil. This involved creating a 'private' schema and moving all tables to it. Functions remain in public, and secured views are created there which can be accessed by normal users. In doing so, I found to my extreme displeasure that although the d

Re: [HACKERS] optimizing constant quals within outer joins

On Wed, Jun 28, 2006 at 11:40:52AM -0400, Tom Lane wrote: > Phil Frost <[EMAIL PROTECTED]> writes: > > The planner in fact can move the function around without changing the > > output. > > Not when it's within the nullable side of an outer join --- moving a >

Re: [HACKERS] optimizing constant quals within outer joins

On Wed, Jun 28, 2006 at 05:11:59PM +0200, Martijn van Oosterhout wrote: > On Wed, Jun 28, 2006 at 10:35:37AM -0400, Phil Frost wrote: > > I have an optimization I'd like to see which I think should be pretty > > easy for someone familiar with the planner code to implement. My &

[HACKERS] optimizing constant quals within outer joins

I have an optimization I'd like to see which I think should be pretty easy for someone familiar with the planner code to implement. My situation is this: I have an application using veil[1]. Essentially, I have a schema "private" and another "public". Private contains regular tables, where private