On Thu, 19 May 2005, Neil Conway wrote:
+errmsg(currval of sequence with OID %d is not
yet defined in this session,
+ last_used_seq-relid)));
See above; however, when will this error actually be invoked? (The
On Sun, 2005-06-05 at 10:20 +1000, Neil Conway wrote:
Bruce Momjian wrote:
Could we do your NOLOGGING automatically in COPY if we test to see if
anyone else is connected to our current database?
Remember that this patch doe NOT yet handle COPY, but that is planned...
That seems pretty
If you're busy, I can clean this up and apply it.
I wonder if it would be better to have lastval() return the last value
returned by nextval() or setval() for the current session, regardless of
any intervening DROP SEQUENCE commands. This would simplify the
implementation (we can just store
At 2005-06-06 12:18:22 +1000, [EMAIL PROTECTED] wrote:
Comments?
Could someone who likes this idea please write the documentation for it?
I'd really like to see a concise, complete description of the proposed
function, including potential caveats.
-- ams
---(end of
Abhijit Menon-Sen wrote:
Could someone who likes this idea please write the documentation for it?
Dennis' original patch includes documentation updates and a description
of lastval():
http://archives.postgresql.org/pgsql-patches/2005-05/msg00059.php
I'd really like to see a concise,
Neil Conway [EMAIL PROTECTED] writes:
Abhijit Menon-Sen wrote:
I'd really like to see a concise, complete description of the proposed
function, including potential caveats.
lastval() returns the last value produced by nextval() or setval() in
the current session.
This definition is OK with
Tom Lane wrote:
This definition is OK with me ... so long as it still includes the
phrase an error occurs if no nextval or setval has occurred in the
current session. However it seemed that a number of people asking
for the feature wanted some-random-default to be returned instead.
Right --
Neil Conway [EMAIL PROTECTED] writes:
Per my earlier mail, the other debatable behavior is whether
lastval() should be defined if the sequence it would be returning the
currval() for has been subsequently dropped. I'm inclined to not return
an error here to simplify the implementation, but
Tom Lane wrote:
I agree with that --- consider that you couldn't actually promise that
the sequence hadn't been dropped by the time the answer is returned,
anyway, unless you take out a lock on the sequence first. Which doesn't
seem like a behavior that is wanted here.
The only objection I
Neil Conway [EMAIL PROTECTED] writes:
The only objection I can see is that it arguably doesn't obey sequence
permissions: you need SELECT on a sequence to see its currval(), whereas
lastval() would return the same information without an equivalent
permission check.
Interesting point ...
10 matches
Mail list logo
