On Wed, Jan 7, 2015 at 6:22 AM, Peter Eisentraut pete...@gmx.net wrote:
I have written similar logic, and while it's not pleasant, it's doable.
This issue would really only go away if you don't use a file to signal
recovery at all, which you have argued for, but which is really a
separate and
On 2015-01-16 21:43:43 +0900, Michael Paquier wrote:
On Wed, Jan 7, 2015 at 6:22 AM, Peter Eisentraut pete...@gmx.net wrote:
I have written similar logic, and while it's not pleasant, it's doable.
This issue would really only go away if you don't use a file to signal
recovery at all, which
On Fri, Jan 16, 2015 at 9:45 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2015-01-16 21:43:43 +0900, Michael Paquier wrote:
On Wed, Jan 7, 2015 at 6:22 AM, Peter Eisentraut pete...@gmx.net wrote:
I have written similar logic, and while it's not pleasant, it's doable.
This issue would
On 2015-01-05 11:27:57 -0500, Robert Haas wrote:
On Sat, Jan 3, 2015 at 7:31 PM, Andres Freund and...@2ndquadrant.com wrote:
* I wonder if parallel contexts shouldn't be tracked via resowners
That is a good question. I confess that I'm somewhat fuzzy about
which things should be tracked
On 2015-01-16 21:50:16 +0900, Michael Paquier wrote:
On Fri, Jan 16, 2015 at 9:45 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2015-01-16 21:43:43 +0900, Michael Paquier wrote:
On Wed, Jan 7, 2015 at 6:22 AM, Peter Eisentraut pete...@gmx.net wrote:
I have written similar logic, and
On 16/01/2015 01:06, Jim Nasby wrote:
On 1/15/15 5:26 AM, Gilles Darold wrote:
Hello,
There's a long pending issue with pg_dump and extensions that have
table members with foreign keys. This was previously reported in this
thread
Hi,
/*
- * Grab an exclusive lock on the pk table, so that someone doesn't
delete
- * rows out from under us. (Although a lesser lock would do for that
- * purpose, we'll need exclusive lock anyway to add triggers to the pk
- * table; trying to start with a lesser
On Thu, Jan 15, 2015 at 5:10 PM, Peter Geoghegan p...@heroku.com wrote:
On Thu, Jan 15, 2015 at 3:00 PM, Merlin Moncure mmonc...@gmail.com wrote:
Running this test on another set of hardware to verify -- if this
turns out to be a false alarm which it may very well be, I can only
offer my
On Fri, Jan 16, 2015 at 8:47 AM, Michael Paquier
michael.paqu...@gmail.com wrote:
Voting for palloc_noerror() as well.
And here is an updated patch using this naming, added to the next CF as well.
--
Michael
From b636c809c2f2cb4177bedc2e5a4883a79b61fbc6 Mon Sep 17 00:00:00 2001
From: Michael
On 2015-01-16 08:47:10 +0900, Michael Paquier wrote:
On Fri, Jan 16, 2015 at 12:57 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
I do think that safe is the wrong suffix. Maybe palloc_soft_fail()
or palloc_null() or palloc_no_oom() or palloc_unsafe().
I liked palloc_noerror()
On 2015-01-16 23:06:12 +0900, Michael Paquier wrote:
/*
+ * Wrappers for allocation functions.
+ */
+static void *set_alloc_internal(MemoryContext context,
+ Size size, bool
noerror);
+static void
On 01/16/2015 03:01 PM, Andres Freund wrote:
Hi,
/*
-* Grab an exclusive lock on the pk table, so that someone doesn't
delete
-* rows out from under us. (Although a lesser lock would do for that
-* purpose, we'll need exclusive lock anyway to add triggers to
On Fri, Jan 16, 2015 at 8:05 AM, Merlin Moncure mmonc...@gmail.com wrote:
On Thu, Jan 15, 2015 at 5:10 PM, Peter Geoghegan p...@heroku.com wrote:
On Thu, Jan 15, 2015 at 3:00 PM, Merlin Moncure mmonc...@gmail.com wrote:
Running this test on another set of hardware to verify -- if this
turns
On 01/16/2015 04:05 PM, Merlin Moncure wrote:
On Thu, Jan 15, 2015 at 5:10 PM, Peter Geoghegan p...@heroku.com wrote:
On Thu, Jan 15, 2015 at 3:00 PM, Merlin Moncure mmonc...@gmail.com wrote:
Running this test on another set of hardware to verify -- if this
turns out to be a false alarm which
Hi,
On 2015-01-16 08:05:07 -0600, Merlin Moncure wrote:
On Thu, Jan 15, 2015 at 5:10 PM, Peter Geoghegan p...@heroku.com wrote:
On Thu, Jan 15, 2015 at 3:00 PM, Merlin Moncure mmonc...@gmail.com wrote:
Running this test on another set of hardware to verify -- if this
turns out to be a
On Fri, Jan 16, 2015 at 8:22 AM, Andres Freund and...@2ndquadrant.com wrote:
Is there any chance you can package this somehow so that others can run
it locally? It looks hard to find the actual bug here without adding
instrumentation to to postgres.
That's possible but involves a lot of
On Thu, Jan 15, 2015 at 10:57 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Hmm, I understood Tom to be opposing the idea of a palloc variant that
returns NULL on failure, and I understand you to be supporting it.
But maybe I'm confused.
Your understanding seems correct to me. I was
Robert Haas wrote:
On Thu, Jan 15, 2015 at 10:57 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
I do think that safe is the wrong suffix. Maybe palloc_soft_fail()
or palloc_null() or palloc_no_oom() or palloc_unsafe().
I liked palloc_noerror() better myself FWIW.
I don't care
Hi all,
As mentioned in $subject, commit 08c33c4 of 2003 has made the
following block of code dead in tablefunc.c:1320 because level is
incremented to at least 1:
/* First time through, do a little more setup */
if (level == 0)
{
On Fri, Jan 16, 2015 at 05:43:44AM -0500, Dave Cramer wrote:
On 16 January 2015 at 01:33, Noah Misch n...@leadboat.com wrote:
Sure, done. Dave, orangutan should now be able to pass with --enable-nls.
Would you restore that option?
I can, but is this for HEAD or all versions ?
All
Michael Paquier wrote:
As mentioned in $subject, commit 08c33c4 of 2003 has made the
following block of code dead in tablefunc.c:1320 because level is
incremented to at least 1:
/* First time through, do a little more setup */
if (level == 0)
On 16 January 2015 at 01:33, Noah Misch n...@leadboat.com wrote:
On Thu, Jan 15, 2015 at 09:24:01AM -0500, Robert Haas wrote:
On Thu, Jan 15, 2015 at 1:04 AM, Noah Misch n...@leadboat.com wrote:
On Wed, Jan 14, 2015 at 04:48:53PM -0500, Peter Eisentraut wrote:
What I'm seeing now is that
On 2015-01-16 12:09:25 -0300, Alvaro Herrera wrote:
Robert Haas wrote:
On Thu, Jan 15, 2015 at 10:57 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
I do think that safe is the wrong suffix. Maybe palloc_soft_fail()
or palloc_null() or palloc_no_oom() or palloc_unsafe().
I
Andres Freund wrote:
On 2015-01-16 12:09:25 -0300, Alvaro Herrera wrote:
Robert Haas wrote:
On Thu, Jan 15, 2015 at 10:57 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
I do think that safe is the wrong suffix. Maybe palloc_soft_fail()
or palloc_null() or palloc_no_oom()
On 2015-01-16 15:16:20 +0100, Andreas Karlsson wrote:
Indeed. As Noah and I discussed previously in this thread we would need to
do quite a bit of refactoring of ruleutils.c to make it fully MVCC.
Right.
For this reason I opted to only lower the lock levels of ADD and ALTER
TRIGGER, and not
On 2015-01-16 12:56:18 -0300, Alvaro Herrera wrote:
Andres Freund wrote:
We rely on palloc erroring out on large allocations in a couple places
as a crosscheck. I don't think this argument holds much water.
I don't understand what that has to do with it. Surely we're not going
to have
On Fri, Jan 16, 2015 at 12:54 PM, Amit Kapila amit.kapil...@gmail.com wrote:
On Thu, Jan 15, 2015 at 9:48 PM, Sawada Masahiko sawada.m...@gmail.com
wrote:
On Thu, Jan 15, 2015 at 2:02 PM, Amit Kapila amit.kapil...@gmail.com
wrote:
One thought I have in this line is that currently there
Andres Freund wrote:
On 2015-01-16 12:56:18 -0300, Alvaro Herrera wrote:
So how about something like
#define ALLOCFLAG_HUGE 0x01
#define ALLOCFLAG_NO_ERROR_ON_OOM 0x02
void *
MemoryContextAllocFlags(MemoryContext context, Size size, int flags);
I don't know,
On 2014-12-25 01:26:53 +1300, David Rowley wrote:
So I think v3 is the one to go with, and I can't see any problems with it,
so I'm marking it as ready for committer.
And committed.
Thanks Teodor and David.
Greetings,
Andres Freund
--
Andres Freund
On 14/01/15 17:22, Gabriele Bartolini wrote:
My opinion, Marco, is that for version 5 of this patch, you:
1) update the information on the wiki (it is outdated - I know you have
been busy with LSN map optimisation)
Done.
2) modify pg_basebackup in order to accept a directory (or tar
On 1/16/15 3:39 AM, Pavel Stehule wrote:
I am proposing a simple function, that returns a position of element in array.
Yes please!
FUNCTION array_position(anyarray, anyelement) RETURNS int
That won't work on a multi-dimensional array. Ideally it needs to accept a
slice or an element and
What's the current status of this topic?
Has someone worked on temporal tables for PostgreSQL since 2012 ?
I'm giving a presentation on Fosdem later this month in Brussels, on the
topic of temporal tables, and would like to give all possibly relevant
information to the audience!
-- Peter
Hi all,
some time ago, I proposed a lock time measurement related to query. A main
issue was a method, how to show this information. Today proposal is little
bit simpler, but still useful. We can show a total lock time per database
in pg_stat_database statistics. High number can be signal about
On 2014-12-15 19:38:16 +0300, Alex Shulgin wrote:
Attached is the modified version of the original patch by Craig,
addressing the handling of the new hint_log error data field and
removing the client-side HINT.
I'm not a big fan of this implementation. We're adding a fair bit of
infrastructure
On 1/16/15 3:45 AM, Pavel Stehule wrote:
I am returning back to processing records in plpgsql.
I am thinking so it can be simply processed with transformations to array.
Now we have similar functions - hstore(row), row_to_json, ... but using of
these functions can be a useless step. Any row
On 2015-01-16 18:01:24 +0100, Andres Freund wrote:
Why don't we just add emit a NOTICE or WARNING in the relevant place
saying that pg_hba.conf is outdated? Then the server won't log those if
configured appropriately, which doesn't seem like a bad thing. Note that
= ERROR messages aren't sent
On 01/16/2015 03:30 AM, Peter Eisentraut wrote:
Here is a random bag of comments for the v5 patch:
Addressed most of your comments, and Michael's. Another version
attached. More on a few of the comments below.
The option --source-server had be confused at first, because the entry
above
Andres Freund and...@2ndquadrant.com writes:
On 2014-12-25 01:26:53 +1300, David Rowley wrote:
So I think v3 is the one to go with, and I can't see any problems with it,
so I'm marking it as ready for committer.
And committed.
It strikes me that this patch leaves some lookups on the table,
2015-01-16 17:57 GMT+01:00 Jim Nasby jim.na...@bluetreble.com:
On 1/16/15 3:39 AM, Pavel Stehule wrote:
I am proposing a simple function, that returns a position of element in
array.
Yes please!
FUNCTION array_position(anyarray, anyelement) RETURNS int
That won't work on a
On 2015-01-16 12:15:35 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-12-25 01:26:53 +1300, David Rowley wrote:
So I think v3 is the one to go with, and I can't see any problems with it,
so I'm marking it as ready for committer.
And committed.
It strikes
Andres Freund and...@2ndquadrant.com writes:
Why don't we just add emit a NOTICE or WARNING in the relevant place
saying that pg_hba.conf is outdated? Then the server won't log those if
configured appropriately, which doesn't seem like a bad thing. Note that
= ERROR messages aren't sent to the
2015-01-16 18:03 GMT+01:00 Jim Nasby jim.na...@bluetreble.com:
On 1/16/15 3:45 AM, Pavel Stehule wrote:
I am returning back to processing records in plpgsql.
I am thinking so it can be simply processed with transformations to array.
Now we have similar functions - hstore(row), row_to_json,
On 1/16/15 11:00 AM, Pavel Stehule wrote:
Hi all,
some time ago, I proposed a lock time measurement related to query. A main
issue was a method, how to show this information. Today proposal is little bit
simpler, but still useful. We can show a total lock time per database in
On 2015-01-16 12:21:13 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
Why don't we just add emit a NOTICE or WARNING in the relevant place
saying that pg_hba.conf is outdated? Then the server won't log those if
configured appropriately, which doesn't seem like a bad
On Wed, Jan 14, 2015 at 9:07 PM, Amit Langote
langote_amit...@lab.ntt.co.jp wrote:
* It has been repeatedly pointed out that we may want to decouple
partitioning from inheritance because implementing partitioning as an
extension of inheritance mechanism means that we have to keep all the
Andres Freund and...@2ndquadrant.com writes:
On 2015-01-16 12:15:35 -0500, Tom Lane wrote:
It strikes me that this patch leaves some lookups on the table,
specifically that it fails to avoid repeated hash_search lookups
inside tbm_page_is_lossy() in the situation where we're adding
new TIDs
2015-01-16 18:23 GMT+01:00 Jim Nasby jim.na...@bluetreble.com:
On 1/16/15 11:00 AM, Pavel Stehule wrote:
Hi all,
some time ago, I proposed a lock time measurement related to query. A
main issue was a method, how to show this information. Today proposal is
little bit simpler, but still
On 1/16/15 11:16 AM, Pavel Stehule wrote:
2015-01-16 17:57 GMT+01:00 Jim Nasby jim.na...@bluetreble.com
mailto:jim.na...@bluetreble.com:
On 1/16/15 3:39 AM, Pavel Stehule wrote:
I am proposing a simple function, that returns a position of element in
array.
Yes please!
Andres Freund and...@2ndquadrant.com writes:
On 2015-01-16 12:21:13 -0500, Tom Lane wrote:
I think people felt that sending that information to the client wouldn't
be a good idea security-wise.
It won't if issued during the right phase of the authentication:
Good point.
But as I don't
On Thu, Jan 15, 2015 at 7:06 AM, Michael Paquier
michael.paqu...@gmail.com wrote:
Alexander Korotkov wrote:
I'm not sure. On the one hand it's unclear why fillfactor should be
different from 9.4.
On the other hand it's unclear why it should be different from btree.
I propose marking this
On 1/16/15 11:22 AM, Pavel Stehule wrote:
2015-01-16 18:03 GMT+01:00 Jim Nasby jim.na...@bluetreble.com
mailto:jim.na...@bluetreble.com:
On 1/16/15 3:45 AM, Pavel Stehule wrote:
I am returning back to processing records in plpgsql.
I am thinking so it can be simply
Hi,
On 2015-01-05 17:16:43 +0900, Michael Paquier wrote:
+ varlistentry id=restore-command-retry-interval
xreflabel=restore_command_retry_interval
+ termvarnamerestore_command_retry_interval/varname
(typeinteger/type)
+ indexterm
+
2015-01-16 18:42 GMT+01:00 Jim Nasby jim.na...@bluetreble.com:
On 1/16/15 11:22 AM, Pavel Stehule wrote:
2015-01-16 18:03 GMT+01:00 Jim Nasby jim.na...@bluetreble.com mailto:
jim.na...@bluetreble.com:
On 1/16/15 3:45 AM, Pavel Stehule wrote:
I am returning back to processing
On 1/16/15 11:35 AM, Pavel Stehule wrote:
2015-01-16 18:23 GMT+01:00 Jim Nasby jim.na...@bluetreble.com
mailto:jim.na...@bluetreble.com:
On 1/16/15 11:00 AM, Pavel Stehule wrote:
Hi all,
some time ago, I proposed a lock time measurement related to query. A
main issue
2015-01-16 18:37 GMT+01:00 Jim Nasby jim.na...@bluetreble.com:
On 1/16/15 11:16 AM, Pavel Stehule wrote:
2015-01-16 17:57 GMT+01:00 Jim Nasby jim.na...@bluetreble.com mailto:
jim.na...@bluetreble.com:
On 1/16/15 3:39 AM, Pavel Stehule wrote:
I am proposing a simple function,
On Wed, Jan 14, 2015 at 9:00 PM, Jim Nasby jim.na...@bluetreble.com wrote:
Simply doing
something like blkno % num_workers is going to cause imbalances,
Yes.
but trying
to do this on a per-block basis seems like too much overhead.
...but no. Or at least, I doubt it. The cost of handing
2015-01-16 19:06 GMT+01:00 Jim Nasby jim.na...@bluetreble.com:
On 1/16/15 11:35 AM, Pavel Stehule wrote:
2015-01-16 18:23 GMT+01:00 Jim Nasby jim.na...@bluetreble.com mailto:
jim.na...@bluetreble.com:
On 1/16/15 11:00 AM, Pavel Stehule wrote:
Hi all,
some time ago,
On Thu, Jan 15, 2015 at 5:46 PM, Peter Geoghegan p...@heroku.com wrote:
I think that it might be a good idea to have circular _bt_moveright()
moves (the direct offender in Merlin's case, which has very similar
logic to your _bt_getstackbuf() problem case) detected. I'm pretty
sure that it's
2015-01-16 19:24 GMT+01:00 Pavel Stehule pavel.steh...@gmail.com:
2015-01-16 19:06 GMT+01:00 Jim Nasby jim.na...@bluetreble.com:
On 1/16/15 11:35 AM, Pavel Stehule wrote:
2015-01-16 18:23 GMT+01:00 Jim Nasby jim.na...@bluetreble.com mailto:
jim.na...@bluetreble.com:
On 1/16/15
On Fri, Jan 16, 2015 at 8:22 AM, Andres Freund and...@2ndquadrant.com wrote:
Hi,
On 2015-01-16 08:05:07 -0600, Merlin Moncure wrote:
On Thu, Jan 15, 2015 at 5:10 PM, Peter Geoghegan p...@heroku.com wrote:
On Thu, Jan 15, 2015 at 3:00 PM, Merlin Moncure mmonc...@gmail.com wrote:
Running
On 1/16/15 12:30 PM, Pavel Stehule wrote:
2015-01-16 19:24 GMT+01:00 Pavel Stehule pavel.steh...@gmail.com
mailto:pavel.steh...@gmail.com:
2015-01-16 19:06 GMT+01:00 Jim Nasby jim.na...@bluetreble.com
mailto:jim.na...@bluetreble.com:
On 1/16/15 11:35 AM, Pavel Stehule wrote:
On 01/16/2015 12:22 PM, Pavel Stehule wrote:
There two possible transformations:
row_to_array -- [[key1, value1],[key2, value2], ...]
row_to_row_array -- [(key1, value1), (key2, value2), ... ]
If we're going to go that route, I think it makes more sense to
On 2015-01-03 12:07:29 +0200, Heikki Linnakangas wrote:
@@ -941,6 +936,8 @@ StartLogicalReplication(StartReplicationCmd *cmd)
* Force a disconnect, so that the decoding code doesn't need to care
* about an eventual switch from running in recovery, to running in a
* normal
On 01/15/2015 09:57 PM, Robert Haas wrote:
On Thu, Jan 15, 2015 at 3:08 AM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Mon, Dec 22, 2014 at 7:31 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Here's an updated version, rebased over the pairing heap code that I just
committed,
On Fri, Jan 16, 2015 at 10:33 AM, Merlin Moncure mmonc...@gmail.com wrote:
ISTM the next step is to bisect the problem down over the weekend in
order to to narrow the search. If that doesn't turn up anything
productive I'll look into taking other steps.
That might be the quickest way to do
On Sat, Jan 17, 2015 at 2:40 AM, Robert Haas robertmh...@gmail.com wrote:
There's only value in adding a fillfactor parameter to GIN indexes if
it improves performance. There are no benchmarks showing it does.
So, why are we still talking about this?
Indeed. There is no such benchmark as of
Timmer, Marius marius.tim...@uni-muenster.de writes:
attached is version 8, fixing remaining issues, adding docs and tests as
requested/agreed.
I've committed this with some rather substantial alterations, notably:
* Having get_sortorder_by_keyno dig into the plan state node by itself
seemed
Hi,
We are seeing a strange behavior where n_live_tup is way smaller than the
number of rows in a table. The table has 18m rows, but n_live_tup only has
100K. We tried to do vacuum analyze to clear up any sticky errors, but it
didn’t correct the problem. We are running Postgres 9.2. Any
On Fri, Jan 16, 2015 at 6:21 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
It looks very much like that a page has for some reason been moved to a
different block number. And that's exactly what Peter found out in his
investigation too; an index page was mysteriously copied to a
Lisa Guo l...@fb.com writes:
We are seeing a strange behavior where n_live_tup is way smaller than the
number of rows in a table. The table has 18m rows, but n_live_tup only has
100K. We tried to do vacuum analyze to clear up any sticky errors, but it
didnt correct the problem. We are
The server did crash yesterday. It has many schemas that have the same table
(different shards). Operations done on these tables are very similar, but only
a few of them actually have this problem. Other than this error, we do not see
other abnormalities on the box.
Lisa
From: Tom Lane
On Fri, Jan 16, 2015 at 9:55 PM, Sawada Masahiko sawada.m...@gmail.com
wrote:
On Fri, Jan 16, 2015 at 12:54 PM, Amit Kapila amit.kapil...@gmail.com
wrote:
I don't know how appealing it would be to others, but a new view
like pg_file_settings which would display the settings in file could
On Fri, Jan 16, 2015 at 11:49 PM, Robert Haas robertmh...@gmail.com wrote:
As mentioned downthread, a far bigger consideration is the I/O pattern
we create. A sequential scan is so-called because it reads the
relation sequentially. If we destroy that property, we will be more
than slightly
Sawada Masahiko wrote
On Fri, Jan 16, 2015 at 12:54 PM, Amit Kapila lt;
amit.kapila16@
gt; wrote:
On Thu, Jan 15, 2015 at 9:48 PM, Sawada Masahiko lt;
sawada.mshk@
gt;
wrote:
On Thu, Jan 15, 2015 at 2:02 PM, Amit Kapila lt;
amit.kapila16@
gt;
wrote:
One thought I have in this
On Fri, Jan 16, 2015 at 11:27 PM, Amit Kapila amit.kapil...@gmail.com wrote:
On Fri, Jan 16, 2015 at 11:49 PM, Robert Haas robertmh...@gmail.com wrote:
As mentioned downthread, a far bigger consideration is the I/O pattern
we create. A sequential scan is so-called because it reads the
On Sat, Jan 17, 2015 at 10:02 AM, David G Johnston
david.g.johns...@gmail.com wrote:
You're right.
pg_setting and SHOW command use value in current session rather than
config file.
It might break these common infrastructure.
Two changes solve this problem in what seems to be a clean
On Fri, Jan 16, 2015 at 10:08 PM, Amit Kapila amit.kapil...@gmail.com
wrote:
On Sat, Jan 17, 2015 at 10:02 AM, David G Johnston
david.g.johns...@gmail.com wrote:
You're right.
pg_setting and SHOW command use value in current session rather than
config file.
It might break these
On Sat, Jan 17, 2015 at 10:41 AM, David Johnston david.g.johns...@gmail.com
wrote:
On Fri, Jan 16, 2015 at 10:08 PM, Amit Kapila amit.kapil...@gmail.com
wrote:
On Sat, Jan 17, 2015 at 10:02 AM, David G Johnston
david.g.johns...@gmail.com wrote:
You're right.
pg_setting and SHOW command
On Fri, Jan 16, 2015 at 10:19 PM, Amit Kapila amit.kapil...@gmail.com
wrote:
On Sat, Jan 17, 2015 at 10:41 AM, David Johnston
david.g.johns...@gmail.com wrote:
On Fri, Jan 16, 2015 at 10:08 PM, Amit Kapila amit.kapil...@gmail.com
wrote:
On Sat, Jan 17, 2015 at 10:02 AM, David G Johnston
2015-01-16 22:35 GMT+01:00 Andrew Dunstan and...@dunslane.net:
On 01/16/2015 12:22 PM, Pavel Stehule wrote:
There two possible transformations:
row_to_array -- [[key1, value1],[key2, value2], ...]
row_to_row_array -- [(key1, value1), (key2, value2), ... ]
2015-01-16 20:33 GMT+01:00 Jim Nasby jim.na...@bluetreble.com:
On 1/16/15 12:30 PM, Pavel Stehule wrote:
2015-01-16 19:24 GMT+01:00 Pavel Stehule pavel.steh...@gmail.com
mailto:pavel.steh...@gmail.com:
2015-01-16 19:06 GMT+01:00 Jim Nasby jim.na...@bluetreble.com
81 matches
Mail list logo
