Martijn van Oosterhout writes:
> The info you need is in the operator class. In a sense you do need to
> know the type of index you're scanning, not all indexes use the same
> strategy numbers.
Well what was tripping me up was figuring out the operator class. I just
realized it's in the index's
> 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 have been forbidden in 8.0 are now accessible in 8.1.
>
> It also me
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 with the pe
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 with the permissions of
the role used to create the function (ran the CREATE FUNCTION
On Wed, 2006-07-05 at 06:55 -0400, Agent M wrote:
> Like you said, it would make sense to have binds anywhere where there
> are quoted strings- if only for anti-injection. There could be a "flat"
> plan which simply did the string substitution with the proper escaping
> at execute time.
I don't
On Wed, Jul 05, 2006 at 12:00:05PM -0400, Greg Stark wrote:
>
> I'm a bit confused about how scan keys work. Is there any simple way given a
> list of Datums of the same type as the index tuple attributes to get all
> matching index entries? This is for a non-system index.
A scankey determines wh
Chris Mair wrote:
but it is about 2Gb of data, so just putting a dump cleaned of personal
data somewhere isn't really an option.
I could arrange a dump without the diagnostics, in these 2 tables:
system: < name | operating_system | os_version | compiler |
compiler_version | architecture >
> but it is about 2Gb of data, so just putting a dump cleaned of personal
> data somewhere isn't really an option.
>
> I could arrange a dump without the diagnostics, in these 2 tables:
>
> system: < name | operating_system | os_version | compiler |
> compiler_version | architecture >
> build
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
Greg Stark wrote:
Neil Conway <[EMAIL PROTECTED]> writes:
On Mon, 2006-07-03 at 23:28 -0400, Agent M wrote:
Why can't preparation be used as a global anti-injection facility?
All that work would need to be deferred to EXECUTE-time, which would largely
defeat the purpose of se
Neil Conway <[EMAIL PROTECTED]> writes:
> On Mon, 2006-07-03 at 23:28 -0400, Agent M wrote:
>
> > Why can't preparation be used as a global anti-injection facility?
>
> All that work would need to be deferred to EXECUTE-time, which would largely
> defeat the purpose of server-side prepared stat
I'm a bit confused about how scan keys work. Is there any simple way given a
list of Datums of the same type as the index tuple attributes to get all
matching index entries? This is for a non-system index.
It seems like the only place in the code where non-system index lookups are
done is nodeInd
> > Which is faster will probably depends on what is more common in your DB:
> > row already exists or not. If you know that 99% of the time the row
> > will exist, the update will probably be faster because you'll only
> > execute one query 99% of the time.
>
> OK, but the point of the question i
On Wed, Jul 05, 2006 at 04:59:52PM +0200, Zeugswetter Andreas DCP SD wrote:
> > OK, but the point of the question is that constantly updating
> > a single row steadily degrades performance, would
> > delete/insery also do the same?
> Yes, there is currently no difference (so you should do the upd
> OK, but the point of the question is that constantly updating
> a single row steadily degrades performance, would
> delete/insery also do the same?
Yes, there is currently no difference (so you should do the update).
Of course performance only degrades if vaccuum is not setup correctly.
Andr
Mark Woodward wrote:
On Tue, Jul 04, 2006 at 11:59:27AM +0200, Zdenek Kotala wrote:
Mark,
I don't know how it will exactly works in postgres but my expectations
are:
Mark Woodward wrote:
Is there a difference in PostgreSQL performance between these two
different strategies:
if(!
> On Tue, Jul 04, 2006 at 11:59:27AM +0200, Zdenek Kotala wrote:
>> Mark,
>> I don't know how it will exactly works in postgres but my expectations
>> are:
>>
>> Mark Woodward wrote:
>> >Is there a difference in PostgreSQL performance between these two
>> >different strategies:
>> >
>> >
>> >if(!ex
Joshua D. Drake wrote:
On Tuesday 04 July 2006 22:14, Chris Mair wrote:
Thanks for the stats Andrew. Out of interest, can you easily tabulate
the number of failures against OS?
Or, more generally, even put a dump of the DB (without personal infos
of course :) somewhere?
Bye, Chris.
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
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> can add to pg_opclass's definition method/parameter name and create some API
> (may be, index specific) to propagate parameter's to module's interface
> functions to index.
Huh? You can get them from the index's Relation structure. I don't
think ther
http://archives.postgresql.org/pgsql-hackers/2005-09/msg00851.php
Just to follow up on the discussion of that thread: what's been
implemented is a way to store arbitrary name=value strings in an index's
pg_class entry, and to make these available in a pre-parsed form through
the index relcache e
Hello,
I've got problems building the client libraries. It seems that there this
problem is already known and dicussed this mailing list earlier:
(snip)
Patch applied to CVS HEAD and 8.1.X. Thanks.
Borland CC also needed this change, so I modified your patch appropriately.
--
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Victor B. Wagner
> Sent: 05 July 2006 12:28
> To: pgsql-hackers@postgresql.org
> Subject: [HACKERS] Creating custom Win32 installer
>
> I need to build custom win32 binary package for PostgreSQL.
I need to build custom win32 binary package for PostgreSQL.
I've downloaded source for PGinstaller but found them hard to
understand - WiX toolkit and MSI is totally alien territory for me.
Things I need to modify:
1. Exclude all unneccessary extensions such as PostGIS
2. Add some other extensio
Ühel kenal päeval, T, 2006-07-04 kell 14:53, kirjutas Zeugswetter
Andreas DCP SD:
> > > >Is there a difference in PostgreSQL performance between these two
> > > >different strategies:
> > > >
> > > >
> > > >if(!exec("update foo set bar='blahblah' where name = 'xx'"))
> > > >exec("insert into f
On Mon, 2006-07-03 at 23:28 -0400, Agent M wrote:
> Why are only select, insert, update, and delete supported for $X binds?
This is a property of the way prepared statements are implemented.
Prepared statement parameters can be used in the place of expressions in
optimizeable statements (the actua
26 matches
Mail list logo
