Re: [HACKERS] Prepared statements considered harmful

2006-08-31 Thread Phil Frost
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 in

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

2006-08-28 Thread Phil Frost
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

2006-07-28 Thread Phil Frost
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

2006-07-27 Thread Phil Frost
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

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

2006-07-27 Thread Phil Frost
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

2006-07-27 Thread Phil Frost
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 feature,

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

2006-07-27 Thread Phil Frost
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 documenting a bug turns

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

2006-07-19 Thread Phil Frost
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. ... In doing so, I found to my extreme displeasure that although

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

2006-07-19 Thread Phil Frost
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 specified schema (assuming that the objects' own

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

2006-07-19 Thread Phil Frost
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 quotelook

[HACKERS] feature request: pg_dump --view

2006-07-18 Thread Phil Frost
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

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

2006-07-12 Thread Phil Frost
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 quotelook

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

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

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

2006-07-10 Thread Phil Frost
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 there are ways

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

2006-07-09 Thread Phil Frost
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 qualified developer. If it is not, consider

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

2006-07-06 Thread Phil Frost
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 might

[HACKERS] set search_path in dump output considered harmful

2006-07-05 Thread Phil Frost
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

[HACKERS] lastval exposes information that currval does not

2006-07-05 Thread Phil Frost
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=#

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

2006-07-05 Thread Phil Frost
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 means that the function runs

[HACKERS] optimizing constant quals within outer joins

2006-06-28 Thread Phil Frost
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

Re: [HACKERS] optimizing constant quals within outer joins

2006-06-28 Thread Phil Frost
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 situation is this: I

Re: [HACKERS] optimizing constant quals within outer joins

2006-06-28 Thread Phil Frost
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 WHERE clause up out of that would make