Currently there are FETCH and the (non standard) MOVE commands to work
on cursors.
(I use cursors to display large datasets in a page-wise way, where the
user can move per-page, or, when displaying a single record, per record.
When the user goes back from per-record view to page-view, I have to
On 02/09/2015 11:37 AM, Marc Balmer wrote:
Currently there are FETCH and the (non standard) MOVE commands to work
on cursors.
(I use cursors to display large datasets in a page-wise way, where the
user can move per-page, or, when displaying a single record, per record.
When the user goes back
Hi
2015-02-09 10:37 GMT+01:00 Marc Balmer m...@msys.ch:
Currently there are FETCH and the (non standard) MOVE commands to work
on cursors.
(I use cursors to display large datasets in a page-wise way, where the
user can move per-page, or, when displaying a single record, per record.
When
2015-02-09 10:37 GMT+01:00 Marc Balmer m...@msys.ch mailto:m...@msys.ch:
Currently there are FETCH and the (non standard) MOVE commands to work
on cursors.
(I use cursors to display large datasets in a page-wise way, where the
user can move per-page, or, when displaying
Heikki Linnakangas hlinnakan...@vmware.com writes:
On 02/09/2015 03:21 AM, Tom Lane wrote:
Meh. I don't care for that much --- it sounds a lot like deciding that
your problem is a nail because there is a hammer within reach. A random
collection of ranges doesn't seem like a very appropriate
On Mon, Feb 9, 2015 at 5:38 AM, Magnus Hagander mag...@hagander.net wrote:
On Mon, Feb 9, 2015 at 11:09 AM, Marco Nenciarini
marco.nenciar...@2ndquadrant.it wrote:
Il 08/02/15 17:04, Magnus Hagander ha scritto:
Filenames are now shown for attachments, including a direct link to the
Amit Langote langote_amit...@lab.ntt.co.jp writes:
Okay, let me back up a little and think about your suggestion which I do
not seem to understand very well - it raises a few questions for me:
does this mean a partitioning criteria is associated with parent
(partitioned table) rather than each
On 2015/02/07 1:09, Tom Lane wrote:
IIRC, this code was written at a time when we didn't have NO INHERIT check
constraints and so it was impossible for the parent table to get optimized
away while leaving children. So the comment in ExplainModifyTarget was
good at the time. But it no longer
I am up for mentoring again.
On 10 Feb 2015 02:23, Thom Brown t...@linux.com wrote:
Hi all,
Google Summer of Code 2015 is approaching. I'm intending on registering
PostgreSQL again this year.
Before I do that, I'd like to have an idea of how many people are
interested in being either a
On 2015/02/10 7:23, Dean Rasheed wrote:
On 9 February 2015 at 21:17, Stephen Frost sfr...@snowman.net wrote:
On Fri, Jan 30, 2015 at 5:20 AM, Etsuro Fujita
I noticed that when updating security barrier views on foreign tables,
we fail to give FOR UPDATE to selection queries issued at
On Mon, Feb 9, 2015 at 10:36 AM, Tom Lane t...@sss.pgh.pa.us wrote:
It's going to be complicated and probably buggy, and I think it is heading
in the wrong direction altogether. If you want to partition in some
arbitrary complicated fashion that the system can't reason about very
effectively,
Robert Haas robertmh...@gmail.com writes:
On Mon, Feb 9, 2015 at 10:36 AM, Tom Lane t...@sss.pgh.pa.us wrote:
It's going to be complicated and probably buggy, and I think it is heading
in the wrong direction altogether. If you want to partition in some
arbitrary complicated fashion that the
On Mon, Feb 9, 2015 at 12:37 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Feb 9, 2015 at 10:36 AM, Tom Lane t...@sss.pgh.pa.us wrote:
It's going to be complicated and probably buggy, and I think it is heading
in the wrong direction altogether. If
Branch: master [804b6b6db] 2015-01-28 12:31:30 -0500
Branch: REL9_4_STABLE Release: REL9_4_1 [3cc74a3d6] 2015-01-28 12:32:06 -0500
Branch: REL9_3_STABLE Release: REL9_3_6 [4b9874216] 2015-01-28 12:32:39 -0500
Branch: REL9_2_STABLE Release: REL9_2_10 [d49f84b08] 2015-01-28 12:32:56 -0500
Branch:
On Sat, 2015-02-07 at 16:08 -0800, Jeff Davis wrote:
I believe Inclusion Constraints will be important for postgres.
I forgot to credit Darren Duncan with the name of this feature:
http://www.postgresql.org/message-id/4f8bb9b0.5090...@darrenduncan.net
Regards,
Jeff Davis
--
Sent
On Mon, Feb 09, 2015 at 12:37:05PM -0500, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
Yeah, but people expect to be able to partition on ranges that are not
all of equal width. I think any proposal that we shouldn't support
that is the kiss of death for a feature like this -
Hello,
A bug had been introduced in the latest versions of the patch. The order of
parameters passed to pglz_decompress was wrong.
Please find attached patch with following correction,
Original code,
+ if (pglz_decompress(block_image, record-uncompressBuf,
+
On Mon, Feb 9, 2015 at 2:54 PM, Tatsuo Ishii wrote:
Agreed. Here is the patch to implement the idea: -f just implies -n.
Some small comments:
- is_no_vacuum, as well as is_init_mode, are defined as an integers
but their use imply that they are boolean switches. This patch sets
is_no_vacuum to
On 2015-02-07 17:16:12 -0500, Robert Haas wrote:
On Sat, Feb 7, 2015 at 4:30 PM, Andres Freund and...@2ndquadrant.com wrote:
[ criticicm of Amit's heapam integration ]
I'm not convinced that that reasoning is generally valid. While it may
work out nicely for seqscans - which might be
I did some more digging on bug
http://www.postgresql.org/message-id/cahul3dpwyfnugdgo95ohydq4kugdnbkptjq0mnbtubhcmg4...@mail.gmail.com
which describes a deadlock when using libpq with SSL in a multi-threaded
environment with other threads doing SSL independently.
Attached is a reproducing Python
On Mon, Feb 9, 2015 at 10:27 PM, Syed, Rahila wrote:
(snip)
Thanks for showing up here! I have not tested the test the patch,
those comments are based on what I read from v17.
Do we always need extra two bytes for compressed backup block?
ISTM that extra bytes are not necessary when the hole
On 10-02-2015 AM 02:37, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Feb 9, 2015 at 10:36 AM, Tom Lane t...@sss.pgh.pa.us wrote:
It's going to be complicated and probably buggy, and I think it is heading
in the wrong direction altogether. If you want to partition in some
Hi all,
Google Summer of Code 2015 is approaching. I'm intending on registering
PostgreSQL again this year.
Before I do that, I'd like to have an idea of how many people are
interested in being either a student or a mentor.
I've volunteered to be admin again, but if anyone else has a strong
Alvaro,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
FWIW using different commit messages for different branches is a
mistake. The implicit policy we have is that there is one message,
identical for all branches, that describe how the patch differs in each
branch whenever necessary.
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
I happened to notice this morning while hacking that the
hasRowSecurity fields added to PlannerGlobal and PlannedStmt have
not been given proper nodefuncs.c support. Both need to be added to
outfuncs.c, and the latter to copyfuncs.c. The
Stephen Frost wrote:
Besides the sloppiness of back-patching in
that one macro and nothing else, this is a huge fraction of the patch
that's just *gone* in the 9.0 and 9.1 branches, and there's not so
much as a hint about it in the commit message, which is pretty
astonishing to me.
While thinking about add_path_precheck() function, it occurred to me that it
can discard some paths that otherwise would have chance be accepted in this
part of add_path():
/*
* Same pathkeys and outer rels, and fuzzily
* the same cost, so keep just one; to decide
Hi,
I want to disable the hashjoin algorithm used by postgres by default, and
enable the nested loop join algorithm, can some one tell me how to do that.
I tried modifying the postgresql.conf file where I set the value
enable_hashjoin=off and also enable_mergejoin=off, so that I could force
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
In 9.2 and newer branches, this commit makes substantial changes to
execMain.c. In 9.1 and 9.0, though, the change to that file is just
this:
--- a/src/backend/executor/execMain.c
+++ b/src/backend/executor/execMain.c
@@ -95,6 +95,15
* Stephen Frost (sfr...@snowman.net) wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
On Fri, Jan 30, 2015 at 5:20 AM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp wrote:
I noticed that when updating security barrier views on foreign tables,
we fail to give FOR UPDATE to selection
On Mon, Feb 9, 2015 at 11:09 AM, Marco Nenciarini
marco.nenciar...@2ndquadrant.it wrote:
Il 08/02/15 17:04, Magnus Hagander ha scritto:
Filenames are now shown for attachments, including a direct link to the
attachment itself. I've also run a job to populate all old threads.
I wonder
On 02/08/2015 08:33 PM, Abhijit Menon-Sen wrote:
At 2015-02-08 18:46:30 +0200, hlinnakan...@vmware.com wrote:
So I propose to move pg_crc.c to src/common, and move the tables
from pg_crc_tables.h directly to pg_crc.c. Thoughts?
Sounds fine to me.
Ok, I've committed a patch that just moves
On Sun, Feb 8, 2015 at 2:54 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Fri, Feb 6, 2015 at 4:58 PM, Fujii Masao wrote:
- * Wait for more WAL to arrive. Time out after 5
seconds,
- * like when polling the archive, to react to a trigger
-
On Mon, Feb 9, 2015 at 7:58 PM, Fujii Masao masao.fu...@gmail.com wrote:
MemoryContextAllocExtended() was added, so isn't it time to replace palloc()
with MemoryContextAllocExtended(CurrentMemoryContext, MCXT_ALLOC_NO_OOM)
in allocate_recordbuf()?
Yeah, let's move on here, but not with this
On Sun, Feb 8, 2015 at 11:03 PM, Robert Haas robertmh...@gmail.com wrote:
On Sat, Feb 7, 2015 at 10:36 PM, Amit Kapila amit.kapil...@gmail.com
wrote:
Well, I agree with you, but I'm not really sure what that has to do
with the issue at hand. I mean, if we were to apply Amit's patch,
we'd
Am 09.02.15 um 11:47 schrieb Marc Balmer:
Am 09.02.15 um 10:46 schrieb Heikki Linnakangas:
[...]
You could fairly easily write an extension to do that, btw. A C function
could call GetPortalByName() and peek into the PortalData.portalPos field.
Would
PGresult
Il 08/02/15 17:04, Magnus Hagander ha scritto:
Filenames are now shown for attachments, including a direct link to the
attachment itself. I've also run a job to populate all old threads.
I wonder what is the algorithm to detect when an attachment is a patch.
If you look at
Am 09.02.15 um 10:46 schrieb Heikki Linnakangas:
[...]
You could fairly easily write an extension to do that, btw. A C function
could call GetPortalByName() and peek into the PortalData.portalPos field.
Would
PGresult *PQdescribePortal(PGconn *conn, const char *portalName);
from libpq
On Mon, Jan 5, 2015 at 1:25 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Thu, Jan 1, 2015 at 1:10 AM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Dec 29, 2014 at 6:14 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Hmm. There is no way to check beforehand if a palloc()
On Mon, Feb 9, 2015 at 2:31 AM, Amit Kapila amit.kapil...@gmail.com wrote:
Another idea is to use Executor level interfaces (like ExecutorStart(),
ExecutorRun(), ExecutorEnd()) for execution rather than using Portal
level interfaces. I have used Portal level interfaces with the
thought that
2015-02-09 10:59 GMT+01:00 Marc Balmer m...@msys.ch:
2015-02-09 10:37 GMT+01:00 Marc Balmer m...@msys.ch mailto:
m...@msys.ch:
Currently there are FETCH and the (non standard) MOVE commands to
work
on cursors.
(I use cursors to display large datasets in a page-wise
On 9 February 2015 at 21:17, Stephen Frost sfr...@snowman.net wrote:
On Fri, Jan 30, 2015 at 5:20 AM, Etsuro Fujita
I noticed that when updating security barrier views on foreign tables,
we fail to give FOR UPDATE to selection queries issued at ForeignScan.
I've looked into this a fair
Am 09.02.15 um 13:13 schrieb Hakan Kocaman:
Hi,
2015-02-09 10:37 GMT+01:00 Marc Balmer m...@msys.ch mailto:m...@msys.ch:
(I use cursors to display large datasets in a page-wise way, where the
user can move per-page, or, when displaying a single record, per record.
When
Hello,
Do we always need extra two bytes for compressed backup block?
ISTM that extra bytes are not necessary when the hole length is zero.
In this case the length of the original backup block (i.e.,
uncompressed) must be BLCKSZ, so we don't need to save the original
size in the extra
Stephen Frost sfr...@snowman.net writes:
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
FWIW using different commit messages for different branches is a
mistake. The implicit policy we have is that there is one message,
identical for all branches, that describe how the patch differs in
Ravi Kiran ravi.kolanp...@gmail.com writes:
I tried modifying the postgresql.conf file where I set the value
enable_hashjoin=off and also enable_mergejoin=off, so that I could force
postgres to use nested loop.
but postgres is still using the hash join algorithm even after modifying
the
At 2015-02-09 12:52:41 +0200, hlinnakan...@vmware.com wrote:
Ok, I've committed a patch that just moves the existing code to
common/pg_crc.c […]
Thanks, looks good.
Attached is a rebased version of the slicing-by-8 patch.
Looks OK too.
Do you have access to big-endian hardware to test
Hi,
2015-02-09 10:37 GMT+01:00 Marc Balmer m...@msys.ch:
(I use cursors to display large datasets in a page-wise way, where the
user can move per-page, or, when displaying a single record, per record.
When the user goes back from per-record view to page-view, I have to
restore the cursor
48 matches
Mail list logo
