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().
Using this function one can do:
# CREATE TABLE abc (a serial, b int);
CREATE TABLE
# SELECT lastval();
ERROR: nextval have not
Dennis Bjorklund [EMAIL PROTECTED] 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
Tom Lane wrote:
Sent: Monday, May 09, 2005 8:37 AM
To: Dennis Bjorklund
Cc: pgsql-patches@postgresql.org
Subject: Re: [PATCHES] lastval()
Dennis Bjorklund [EMAIL PROTECTED] writes:
Here is a small patch that implements a function lastval()
that works
just like currval() except that
I think the read-only has two meanings for the user.
First is the internal state. XID, OID or something like that.
In these cases, the internal state mustn't be changed.
Some users will need the read-only for internal state.
Second is read-only for the user data contents.
In
Satoshi Nagayasu [EMAIL PROTECTED] writes:
I think the read-only has two meanings for the user.
First is the internal state. XID, OID or something like that.
In these cases, the internal state mustn't be changed.
Some users will need the read-only for internal state.
Second is read-only for
On Mon, May 09, 2005 at 09:02:07AM +0900, Satoshi Nagayasu wrote:
I think the read-only has two meanings for the user.
First is the internal state. XID, OID or something like that.
In these cases, the internal state mustn't be changed.
Some users will need the read-only for internal state.
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.
Magnus Hagander wrote:
I guess that's from not reading things carefully enough. I looked for
where backend pid was transmitted, because I thought that would be a
good place to put it.
On adapting the code to just send the client address in the BE start
message, I'm not actually sure this is the
Neil Conway [EMAIL PROTECTED] writes:
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
Tom Lane wrote:
I think this argument is a red herring ... or at least it leads in a
direction I find unacceptable.
I agree -- I was just pointing out the reason that, in the current
design, there is cause to do things as Magnus' original patch did.
We are already transmitting three more fields
Neil Conway [EMAIL PROTECTED] writes:
How about changing the statistics collector so that we only include a
row in the statistics view when we receive the BESTART message?
I'd vote against that. The mechanism is lossy by design and so we
must design on the assumption that we will sometimes
Tom Lane wrote:
I'd vote against that. The mechanism is lossy by design
Is it _lossy_, or merely unordered? While UDP doesn't guarantee message
delivery, I wonder what kind of extreme circumstances would need to
exist for you to lose UDP packets outright over the loopback interface.
I don't
Neil Conway [EMAIL PROTECTED] writes:
Tom Lane wrote:
I'd vote against that. The mechanism is lossy by design
Is it _lossy_, or merely unordered? While UDP doesn't guarantee message
delivery, I wonder what kind of extreme circumstances would need to
exist for you to lose UDP packets
But the second is only a subset of the first, no? So why not just
implement the first? Put another way, why do you think the second is
necessary?
Because there is "default_transaction_read_only" option and
implementation.
My implementation is an extension of the
Satoshi Nagayasu wrote:
I wanted to make the postmaster read-only, and found
"default_transaction_read_only" option, but it can be overwritten.
I mean it can be overridden by the user. I don't want that.
--
NAGAYASU Satoshi [EMAIL PROTECTED]
OpenSource Development
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
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
17 matches
Mail list logo
