Re: lastval exposes information that currval does not - Mailing list pgsql-hackers

From Martijn van Oosterhout
Subject Re: lastval exposes information that currval does not
Date
Msg-id 20060728195438.GA3035@svana.org
Whole thread Raw
In response to Re: lastval exposes information that currval does not  (Stephen Frost <sfrost@snowman.net>)
Responses Re: lastval exposes information that currval does not  (Phil Frost <indigo@bitglue.com>)
List pgsql-hackers
On Thu, Jul 27, 2006 at 09:37:22PM -0400, Stephen Frost wrote:
> Got any others beyond 'lastval'?  Is 'lastval' even doing what you're
> claiming (looking at the actual catalog on disk by using the OID)?  My
> recollection was that it was actually just storing the value in a bit of
> backend-local memory, but I havn't gone and looked at the code yet. Have
> you looked at the code behind 'lastval'?

Well, you got me curious and so I looked at the code in question. The
code does have a check, but it just checks if the user has access to
the sequence. If the user doesn't have SELECT or USAGE on the sequence
in question, lastval() will indeed fail with an error.

> Again, stretching a relatively minor point about lastval to some kind of
> systemic problem, with the servers or the developers, isn't going to get
> anyone anywhere.

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...

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [Pgbuildfarm-members] [Fwd: RE: Build farm on Windows]
Next
From: Tom Lane
Date:
Subject: Re: [PATCHES] pg_regress breaks on msys