On Fri, Apr 24, 2015 at 11:39:04PM -0500, Jim Nasby wrote:
On 4/24/15 7:11 PM, Álvaro Hernández Tortosa wrote:
On 24/04/15 05:24, Tom Lane wrote:
...
TBH, I've got very little enthusiasm for fixing this given the number
of reports of trouble from the field, which so far as I recall is zero.
Robert Haas robertmh...@gmail.com writes:
On Wed, Apr 22, 2015 at 6:12 PM, Jim Nasby jim.na...@bluetreble.com wrote:
As for allowing SQL and plpgsql functions to accept a record, I think our
JSON functionality just provided plenty of reason we should allow accepting
them, even if you can't do
On 2015-04-25 11:50:59 -0700, Peter Geoghegan wrote:
On Sat, Apr 25, 2015 at 11:24 AM, Andres Freund and...@anarazel.de wrote:
c) Right now the UPDATE can refer to pseudo relations 'TARGET' and
'EXCLUDED'. I think especially the latter doesn't fit anymore at
all. How about
Robert Haas robertmh...@gmail.com writes:
No, I just misread your email. I thought you said you had attached
the patch; rereading it, I see that you said you had applied the
patch. Silly me.
The real problem with this patch is it's wrong. Specifically, it broke
the other case I mentioned in
On Sat, Apr 25, 2015 at 06:15:25PM -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
No, I just misread your email. I thought you said you had attached
the patch; rereading it, I see that you said you had applied the
patch. Silly me.
The real problem with this patch is
On Sat, Apr 25, 2015 at 2:01 AM, Andres Freund and...@anarazel.de wrote:
My problem with the WHERE being inside the parens in the above is that
it's
a) different from CREATE INDEX
I don't think that that's an important goal.
b) unclear whether the WHERE belongs to colb or the whole index
Hi
2015-04-24 19:16 GMT+02:00 Joel Jacobson j...@trustly.com:
On Fri, Apr 24, 2015 at 6:07 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
Example:
context_messages = -warning, -error, +notice
I prefer your first proposal - and there is a precedent for plpgsql -
On 04/25/2015 08:01 PM, Michael Paquier wrote:
On Sun, Apr 26, 2015 at 2:19 AM, Andrew Dunstan and...@dunslane.net wrote:
On 04/25/2015 10:53 AM, Michael Paquier wrote:
On Sat, Apr 25, 2015 at 9:58 PM, Peter Eisentraut wrote:
On 4/24/15 12:22 AM, Michael Paquier wrote:
Now that the stuff
On Sat, Apr 25, 2015 at 11:24 AM, Andres Freund and...@anarazel.de wrote:
b) unclear whether the WHERE belongs to colb or the whole index
expression. The equivalent for aggregates, which I bet is going to be
used less often, caused a fair amount of confusing.
I don't see those two
On 04/25/2015 12:32 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 04/24/2015 06:41 PM, Tom Lane wrote:
Yeah, this was brought up when we added per-large-object metadata; it was
obvious that that patch would cause pg_dump to choke on large numbers of
large objects. The
David Rowley dgrowle...@gmail.com writes:
On 24 April 2015 at 21:43, Teodor Sigaev teo...@sigaev.ru wrote:
I faced with planner error:
ERROR: could not find RelOptInfo for given relids
I've done a little debugging on this too and I get the idea that in
eqjoinsel() that min_righthand
+1
On Sat, Apr 25, 2015 at 10:23 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
Hi
2015-04-24 19:16 GMT+02:00 Joel Jacobson j...@trustly.com:
On Fri, Apr 24, 2015 at 6:07 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
Example:
context_messages = -warning, -error, +notice
I
Hi all,
My apologies I couldn't directly respond to the earlier thread on this
subject
(http://www.postgresql.org/message-id/50d99278.3030...@dc.baikal.ru) but
I wasn't subscribed to the list at that point.
I've been working on a conversion of several utilities I wrote for
another engine, and
Etsuro Fujita fujita.ets...@lab.ntt.co.jp writes:
On 2015/04/16 16:05, Etsuro Fujita wrote:
I agree with you on this point. However, ISTM there is a bug in
handling OIDs on foreign tables; while we now allow for ALTER SET
WITH/WITHOUT OIDS, we still don't allow the default_with_oids parameter
On Sat, Apr 25, 2015 at 11:50 AM, Peter Geoghegan p...@heroku.com wrote:
To be fair, there is one unrelated slight difference with RETURNING
and conventional UPDATEs: You cannot return the EXCLUDED tuple (in the
same way that you can reference the joined-FROM tuple within
conventional
On Sat, Apr 25, 2015 at 12:23 PM, Andres Freund and...@anarazel.de wrote:
95% of all users will know NEW/OLD from triggers, not rules. Where NEW
is used in a quite comparable way.
I don't think it's comparable.
Seems pretty descriptive of the situation to me - I actually put a lot
of
On Sat, Apr 25, 2015 at 12:35 PM, Peter Geoghegan p...@heroku.com wrote:
That
it has 'morphing' characteristics imo just makes it worse, rather than
better. Besides being confusing that it has different meanings, it's far
from inconceivable that somebody wants to return values from the
On 04/25/2015 10:53 AM, Michael Paquier wrote:
On Sat, Apr 25, 2015 at 9:58 PM, Peter Eisentraut wrote:
On 4/24/15 12:22 AM, Michael Paquier wrote:
Now that the stuff related to the move from contrib/ to src/bin/,
modulescheck and tmp_install has been committed, shouldn't we give a
new shot
On Sun, Apr 26, 2015 at 2:19 AM, Andrew Dunstan and...@dunslane.net wrote:
On 04/25/2015 10:53 AM, Michael Paquier wrote:
On Sat, Apr 25, 2015 at 9:58 PM, Peter Eisentraut wrote:
On 4/24/15 12:22 AM, Michael Paquier wrote:
Now that the stuff related to the move from contrib/ to src/bin/,
On Saturday, April 25, 2015, Tom Lane t...@sss.pgh.pa.us wrote:
It's perhaps debatable whether it should act that way, but in the absence
of complaints from the field, I'm hesitant to change these cases. It
might be better if the effective behavior were table gets OIDs if
default_with_oids
On Tue, Apr 21, 2015 at 11:38 PM, Robert Haas robertmh...@gmail.com wrote:
After thinking about it a bit more, I realized that even if we settle
on some solution to that problem, there's another issues: the
wait-edges created by this system don't really have the same semantics
as regular
Bruce Momjian br...@momjian.us writes:
I have changed the default value back to the function call as it should
have been all along; patch attached. I will revisit this for 9.6
unless I hear otherwise.
I still don't like this patch one bit. I don't think that this code
should be modifying
On Fri, Apr 24, 2015 at 8:05 PM, Tomas Vondra tomas.von...@2ndquadrant.com
wrote:
On 04/24/15 14:58, Amit Kapila wrote:
On Fri, Apr 24, 2015 at 8:46 AM, Abhijit Menon-Sen a...@2ndquadrant.com
mailto:a...@2ndquadrant.com wrote:
At 2015-04-24 08:35:40 +0530, amit.kapil...@gmail.com
David G. Johnston david.g.johns...@gmail.com writes:
On Saturday, April 25, 2015, Tom Lane t...@sss.pgh.pa.us wrote:
Still another case that needs to be thought about is create table likeit
(like base) without oids where base does have OIDs. Probably the right
thing here is to let the WITHOUT
Le 24/04/2015 21:11, Jim Nasby a écrit :
On 4/24/15 6:29 AM, Robert Haas wrote:
On Thu, Apr 23, 2015 at 9:28 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The reason nobody's gotten around to that in the last fifteen years is
that per-process rusage isn't actually all that interesting; there's
too
On 25 April 2015 at 01:52, Stephen Frost sfr...@snowman.net wrote:
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
The second patch [2] is the one that is actually relevant to this
thread. This patch is primarily to apply the RLS checks earlier,
before an update is attempted, more like a
On 24 April 2015 at 21:43, Teodor Sigaev teo...@sigaev.ru wrote:
Hi!
I faced with planner error:
ERROR: could not find RelOptInfo for given relids
Good find!
I've simplified your query a bit, the following still shows the issue
(using your schema):
SELECT *
FROM t1
WHERE NOT EXISTS
On April 22, 2015 06:04:42 PM Payal Singh wrote:
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: tested, failed
Spec compliant: not tested
Documentation:tested, failed
Error in
On Sat, Apr 25, 2015 at 7:59 AM, Peter Eisentraut pete...@gmx.net wrote:
On 4/23/15 1:22 PM, Jeff Janes wrote:
Something about this commit (dcae5faccab64776376d354d) broke make
check in parallel conditions when started from a clean directory. It
fails with a different error each time, one
On Sat, Apr 25, 2015 at 4:51 AM, Andrew Dunstan and...@dunslane.net wrote:
The optional buildfarm module that runs this test was broken by commit
dcae5faccab64776376d354decda0017c648bb53
Since nobody has responded to my complaint about this, I have disabled it on
crake, the only buildfarm
On Sat, Apr 25, 2015 at 6:14 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Tom Lane wrote:
The current logic in src/test/Makefile, particularly the way that
the modules subdirectory is handled, seems pretty ugly/convoluted
anyway. I wonder why it was
On Sat, Apr 25, 2015 at 9:58 PM, Peter Eisentraut wrote:
On 4/24/15 12:22 AM, Michael Paquier wrote:
Now that the stuff related to the move from contrib/ to src/bin/,
modulescheck and tmp_install has been committed, shouldn't we give a
new shot at this patch? Attached is a rebased version.
On 04/24/2015 06:41 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 04/23/2015 04:04 PM, Andrew Gierth wrote:
The relevant code is getBlobs in pg_dump.c, which queries the whole of
pg_largeobject_metadata without using a cursor (so the PGresult is
already huge thanks to
On 24 April 2015 at 22:36, Jim Nasby jim.na...@bluetreble.com wrote:
Instead of adding forcefsm, I think it would be more useful to accept a
target block number. That way we can actually control where the new tuple
goes. For this particular case we'd presumably go with normal FSM page
On Wed, Mar 18, 2015 at 2:24 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Mar 18, 2015 at 1:23 PM, Fabrízio de Royes Mello
fabriziome...@gmail.com wrote:
If we ever implement something like
COMMENT ON CURRENT_DATABASE IS ...
it will be useful, because you will be able to
On 4/24/15 12:22 AM, Michael Paquier wrote:
On Fri, Mar 13, 2015 at 6:04 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Fri, Mar 13, 2015 at 6:20 AM, Alvaro Herrera wrote:
Peter Eisentraut wrote:
This is contrib/chkpass not finding the crypt symbol, which is
presumably in some
Andrew Dunstan and...@dunslane.net writes:
On 04/24/2015 06:41 PM, Tom Lane wrote:
Yeah, this was brought up when we added per-large-object metadata; it was
obvious that that patch would cause pg_dump to choke on large numbers of
large objects. The (perhaps rather lame) argument was that you
37 matches
Mail list logo
