On Sat, Aug 24, 2013 at 2:46 PM, Sawada Masahiko sawada.m...@gmail.com wrote:
On Sat, Aug 24, 2013 at 3:14 AM, Josh Berkus j...@agliodbs.com wrote:
On 08/23/2013 12:42 AM, Sawada Masahiko wrote:
in case (a), those priority is clear. So I think that re-taking over
is correct behaviour.
OHOT,
On 24/08/2013 21:16, Tom Lane wrote:
Marc Cousin cousinm...@gmail.com writes:
On 23/08/2013 23:55, Tom Lane wrote:
My previous suggestion was to estimate planning cost as
10 * (length(plan-rangetable) + 1)
but on reflection it ought to be scaled by one of the cpu cost constants,
so perhaps
On 08/24/2013 09:08 PM, Daniel Farina wrote:
On Sat, Aug 24, 2013 at 6:04 PM, Daniel Farina dan...@fdr.io wrote:
But there's no good way I can find from the documentation to do it
with a scalar: select ('va\lue'::json)::text;
Triggered send by accident:
select ('va\lue'::json)::text;
Hello
here is a patch
it introduce a load_lo and make_lo functions
postgres=# select make_lo(decode('ff00','hex'));
make_lo
─
24629
(1 row)
Time: 40.724 ms
postgres=# select load_lo(24628);
load_lo
\xff00
(1 row)
postgres=# \lo_import ~/avatar.png
lo_import
2013/8/25 Pavel Stehule pavel.steh...@gmail.com
Hello
here is a patch
it introduce a load_lo and make_lo functions
postgres=# select make_lo(decode('ff00','hex'));
make_lo
─
24629
(1 row)
Time: 40.724 ms
postgres=# select load_lo(24628);
load_lo
This came up recently on -bugs. See
http://www.postgresql.org/message-id/51fbf787.5000...@dunslane.net,
where I suggested we expose the dequoting function.
+1.
As it is, I use btrim() heaviy with JSON data.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via
2013/8/23 Tom Lane t...@sss.pgh.pa.us
Pavel Stehule pavel.steh...@gmail.com writes:
please, can you send a self explained test
this issue should be fixed, and we need a examples.
We already had a perfectly good example at the beginning of this thread.
What's missing is a decision on how
On Thu, Aug 22, 2013 at 11:55 PM, Blake Smith blakesmi...@gmail.com wrote:
We've been experiencing slow @ queries involving an hstore column that's
covered by a Gin index. At the current postgresql git HEAD, the hstore -
gin interface produces the following text items to be indexed:
hstore:
Michael Paquier michael.paqu...@gmail.com writes:
On Thu, Aug 22, 2013 at 11:55 PM, Blake Smith blakesmi...@gmail.com wrote:
The combined entry is used to support contains (@) queries, and the key
only item is used to support key contains (?) queries. This change seems
to help especially with
On Sat, Aug 24, 2013 at 11:38 PM, Peter Eisentraut pete...@gmx.net wrote:
On Thu, 2013-07-11 at 23:42 +0900, Sawada Masahiko wrote:
please find the attached patch.
Please fix these compiler warnings:
xlog.c:3117:2: warning: implicit declaration of function ‘SyncRepWaitForLSN’
On 8/23/13 11:23 AM, Greg Stark wrote:
This doesn't generate a unique id. You could back up a standby and restore it
and point it at the original master and end up with two standbies with the same
id.
If you want to enforce something unique throughout a cluster, I think we're
stuck with
On Mon, Aug 26, 2013 at 7:47 AM, Jim Nasby j...@nasby.net wrote:
On 8/23/13 11:23 AM, Greg Stark wrote:
This doesn't generate a unique id. You could back up a standby and restore
it and point it at the original master and end up with two standbies with
the same id.
If you want to enforce
12 matches
Mail list logo
