|
Home > Archive > PostgreSQL Patches > May 2005 > Re: lastval()
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| Tom Lane 2005-05-08, 8:23 pm |
| Dennis Bjorklund <db@zigo.dhs.org> writes:
> Here is a small patch that implements a function lastval() that
> works just like currval() except that it give the current
> value of the last sequence used by nextval().
Why is that a good idea? In a complex application it'd be awfully easy
to break logic that depends on such a thing.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql
.org
| |
| Neil Conway 2005-05-08, 8:23 pm |
| Tom Lane wrote:
> Why is that a good idea? In a complex application it'd be awfully easy
> to break logic that depends on such a thing.
True, but I think it offers a usefully concise syntax for simpler
applications. Perhaps the documentation should be amended to mention the
potential risks? (e.g. additional nextval() calls in between the
nextval() you are interested in and the lastval()).
-Neil
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
| |
| Tom Lane 2005-05-08, 8:23 pm |
| Neil Conway <neilc@samurai.com> writes:
> Tom Lane wrote:
[color=darkred]
> True, but I think it offers a usefully concise syntax for simpler
> applications. Perhaps the documentation should be amended to mention the
> potential risks?
Like, say, the sequence being deleted before the lastval call?
If I thought it was a good idea at all, I'd bother to criticize the
patch itself --- it's got some problems.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql
.org so that your
message can get through to the mailing list cleanly
| |
| Dennis Bjorklund 2005-05-09, 3:23 am |
| On Sun, 8 May 2005, Tom Lane wrote:
> Why is that a good idea? In a complex application it'd be awfully easy
> to break logic that depends on such a thing.
Of course it can break. currval() can also break in a complex application
with triggers and rules that do things the developer does not expect.
There are however lots of cases where it is safe and useful. Not the least
when you want to port an application that uses similar features.
--
/Dennis Björklund
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings
| |
| Dennis Bjorklund 2005-05-09, 3:23 am |
| On Sun, 8 May 2005, Tom Lane wrote:
> Like, say, the sequence being deleted before the lastval call?
Then you get an error message. Same thing if you have revoked the rights
on the sequence before you call lastval().
In this case you can get a value that belong to a sequence that is
deleted. Is that better? To me it's a sign that something is wrong with
the application and an error is better to get. It's not like it's hard to
store a int64 value instead. It's in fact simpler, but I just don't see
that it solve any problem. If anything it can hide problems.
If you want lastval() to work just don't delete the sequence. It's as
simple as that.
The thing is that I don't care how it's implemented, it's the feature
itself that is more importent to decide if we want it or not. I'm sure the
code can be fixed so everybody is happy it in the end,
--
/Dennis Björklund
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql
.org
| |
| Heikki Linnakangas 2005-05-10, 8:24 pm |
| On Mon, 9 May 2005, Dennis Bjorklund wrote:
> The thing is that I don't care how it's implemented, it's the feature
> itself that is more importent to decide if we want it or not. I'm sure the
> code can be fixed so everybody is happy it in the end,
You could implement this on top of the current nextval without backend
changes.
Create a wrapper function on top of nextval that stores the value in a
temp table. Or a session variable if your PL language of choice has
them.
lastval would do a select on the temp table.
- Heikki
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
| |
| Andrew Dunstan 2005-05-10, 8:24 pm |
|
Heikki Linnakangas wrote:
> On Mon, 9 May 2005, Dennis Bjorklund wrote:
>
>
>
> You could implement this on top of the current nextval without backend
> changes.
>
> Create a wrapper function on top of nextval that stores the value in a
> temp table. Or a session variable if your PL language of choice has them.
>
> lastval would do a select on the temp table.
>
>
And this is making life easier for anybody? I don't think so.
cheers
andrew
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
|
|
|
|
|