On Mon, Sep 2, 2013 at 4:35 PM, Fabrízio de Royes Mello
fabri...@timbira.com.br wrote:
The attached patch fix the items reviewed by you.
Committed with assorted revisions. In particular, I renamed the
function that discards cached sequence data, revised the wording of
the documentation, added a
On Thu, Oct 3, 2013 at 5:26 PM, Robert Haas robertmh...@gmail.com wrote:
Committed with assorted revisions. In particular, I renamed the
function that discards cached sequence data, revised the wording of
the documentation, added a regression test, and tweaked the list-free
code to pop
On 19-08-2013 16:10, Boszormenyi Zoltan wrote:
I am reviewing your patch.
Thanks...
* Is the patch in a patch format which has context? (eg: context diff
format)
Yes.
* Does it apply cleanly to the current git master?
Almost. No rejects, no fuzz, only offset for some files.
* Does it
On Fri, 2013-04-19 at 11:58 -0300, Fabrízio de Royes Mello wrote:
Ohh sorry... you're all right... I completely forgot to finish the
ReleaseSequenceCaches to transverse 'seqtab' linked list and free each
node.
The attached patch have this correct code.
Please fix this compiler warning:
Hi,
2013-04-19 16:58 keltezéssel, Fabrízio de Royes Mello írta:
On Fri, Apr 19, 2013 at 11:12 AM, Robert Haas robertmh...@gmail.com
mailto:robertmh...@gmail.com wrote:
On Fri, Apr 19, 2013 at 10:05 AM, Fabrízio de Royes Mello
fabriziome...@gmail.com mailto:fabriziome...@gmail.com
2013-08-19 21:02 keltezéssel, Boszormenyi Zoltan írta:
Hi,
2013-04-19 16:58 keltezéssel, Fabrízio de Royes Mello írta:
On Fri, Apr 19, 2013 at 11:12 AM, Robert Haas robertmh...@gmail.com
mailto:robertmh...@gmail.com wrote:
On Fri, Apr 19, 2013 at 10:05 AM, Fabrízio de Royes Mello
On 25-07-2013 05:32, suresh.balasubra wrote:
Disclaimer: I am no hacker, just a PostGreSQL user, trying to provide a user
scenario where DISCARD SEQUENCES functionality is required.
We have designed a developed a small Application Development platform for
which the backend is PostGreSQL.
There
Disclaimer: I am no hacker, just a PostGreSQL user, trying to provide a user
scenario where DISCARD SEQUENCES functionality is required.
We have designed a developed a small Application Development platform for
which the backend is PostGreSQL.
There is a DBLayer which is responsible in
On Wed, Apr 17, 2013 at 6:17 PM, Tom Lane t...@sss.pgh.pa.us wrote:
No, it's a critical tool in complexity management. When you're dealing
with systems as complicated as a database, every little non-orthogonal
detail adds up. DISCARD ALL has a clear definition in terms of simpler
commands,
On Fri, Apr 19, 2013 at 10:50 AM, Robert Haas robertmh...@gmail.com wrote:
[...]
So it seems to me that we pretty much already made a decision that the
controlling definition of DISCARD ALL is that, as the fine manual says
DISCARD ALL resets a session to its original state. Whatever
On Fri, Apr 19, 2013 at 10:05 AM, Fabrízio de Royes Mello
fabriziome...@gmail.com wrote:
The attached wip patch do that and introduce a subcommand 'SEQUENCES', but
if we decide to don't add a new subcommand to DISCARD, then its easier to
modify the patch.
This patch is quite wrong. It frees
On 04/19/2013 06:50 AM, Robert Haas wrote:
On Wed, Apr 17, 2013 at 6:17 PM, Tom Lane t...@sss.pgh.pa.us wrote:
No, it's a critical tool in complexity management. When you're dealing
with systems as complicated as a database, every little non-orthogonal
detail adds up. DISCARD ALL has a clear
On Fri, Apr 19, 2013 at 11:12 AM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Apr 19, 2013 at 10:05 AM, Fabrízio de Royes Mello
fabriziome...@gmail.com wrote:
The attached wip patch do that and introduce a subcommand 'SEQUENCES',
but
if we decide to don't add a new subcommand to
Fabrízio de Royes Mello escribió:
Ohh sorry... you're all right... I completely forgot to finish the
ReleaseSequenceCaches to transverse 'seqtab' linked list and free each
node.
The attached patch have this correct code.
It seems a bad idea to backpatch this; whoever wants this
Alvaro Herrera alvhe...@2ndquadrant.com writes:
It seems a bad idea to backpatch this; whoever wants this functionality
in back branches should probably run a patched server.
Surely this is 9.4 material at this point in any case.
regards, tom lane
--
Sent via
On Fri, Apr 19, 2013 at 11:09 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
It seems a bad idea to backpatch this; whoever wants this functionality
in back branches should probably run a patched server.
Surely this is 9.4 material at this point in any
On Tue, Apr 16, 2013 at 05:09:19PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
I think his point is why don't we clear currval() on DISCARD ALL? I
can't think of a good reason we don't.
Because we'd have to invent a new suboperation DISCARD SEQUENCES,
for one thing, in
Marko Kreen mark...@gmail.com writes:
On Tue, Apr 16, 2013 at 05:09:19PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
I think his point is why don't we clear currval() on DISCARD ALL? I
can't think of a good reason we don't.
Because we'd have to invent a new suboperation
On Tue, Apr 16, 2013 at 12:13:48PM -0700, Adrian Klaver wrote:
On 04/16/2013 08:07 AM, Nigel Heron wrote:
On 04/15/2013 05:57 PM, Adrian Klaver wrote:
On 04/15/2013 02:42 PM, Nigel Heron wrote:
Hi,
is there a way to clear the session state of sequence values fetched by
currval(regclass)?
Bruce Momjian br...@momjian.us writes:
I think his point is why don't we clear currval() on DISCARD ALL? I
can't think of a good reason we don't.
Because we'd have to invent a new suboperation DISCARD SEQUENCES,
for one thing, in order to be consistent. I'd rather ask why it's
important that
On Tue, Apr 16, 2013 at 6:09 PM, Tom Lane t...@sss.pgh.pa.us wrote:
[...]
Or, if you'd rather a more direct answer: wanting this sounds like
evidence of bad application design. Why is your app dependent on
getting failures from currval, and isn't there a better way to do it?
The sequence
21 matches
Mail list logo
