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
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 expe
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 Developme
> 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 exist
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 packet
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 t
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 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 t
Neil Conway <[EMAIL PROTECTED]> writes:
> On adapting the code to just send the client address in the BE start
> message, I'm not actually sure this is the right way to go. The problem
> is that stats messages are unordered -- so we might receive, say, an
> activity message for a backend before
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
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
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. ad
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 stat
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-onl
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
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()
On Fri, 6 May 2005, Emmanuel Bernard wrote:
> From the Javadoc of java.sql.Blob byte[] getBytes(long pos, int length)
> throws SQLException;
>
>* @param pos the ordinal position of the first byte in the
>*BLOB value to be extracted; the first byte is at
>*position
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 brea
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
19 matches
Mail list logo
