So, is there any idea how we will handle NULL and empty array in
array_agg(anyarray)?
I propose we just reject those input because the output will make no sense:
- array_agg(NULL::int[]) -- the result will be indistinguished from
array_agg of NULL ints.
- array_agg('{}'::int[]) -- how we
On Oct 19, 2014 4:34 AM, Robert Haas robertmh...@gmail.com wrote:
But TBH I suspect 95% of the problems here would vanish if smart
shutdown weren't the default ...
But for your repeated objections, we would have changed the default to
fast years ago. AFAICT everyone else is in favor of
On Fri, Oct 10, 2014 at 12:33 AM, Peter Geoghegan p...@heroku.com wrote:
Attached
Have you looked at this?
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Oct 17, 2014 at 7:08 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Dag-Erling Smørgrav wrote:
I understand this policy. However, this new feature a) has absolutely
no impact unless the admin makes a conscious decision to use it and b)
will
On Sat, Oct 18, 2014 at 2:25 PM, Feng Tian ft...@vitessedata.com wrote:
Hi, David,
Yes, switch sorting order would loose an interesting order so if user
dictates order by t, i; planner need to resort to its cost model.
Estimating cardinality of groupby is a much bigger topic than this
On Fri, Oct 3, 2014 at 10:41 AM, Marti Raudsepp ma...@juffo.org wrote:
Hi list,
Attached patch allows semijoin/antijoin/hashed SubPlan optimization
when an EXISTS subquery contains a LIMIT clause with a positive
constant. It seems to be a fairly common meme to put LIMIT 1 into
EXISTS()
On Sat, Oct 18, 2014 at 1:39 PM, Tom Lane t...@sss.pgh.pa.us wrote:
David Rowley dgrowle...@gmail.com writes:
On Fri, Oct 17, 2014 at 3:34 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I don't want to go there. It would be a lot better to expend the effort
on a better regression testing
On Fri, Oct 17, 2014 at 4:32 AM, Fabrízio de Royes Mello
fabriziome...@gmail.com wrote:
On Wed, Oct 15, 2014 at 11:41 AM, Sawada Masahiko sawada.m...@gmail.com
wrote:
On Mon, Oct 13, 2014 at 11:16 PM, Robert Haas robertmh...@gmail.com
wrote:
On Sun, Oct 12, 2014 at 1:27 PM, Stephen Frost
Magnus Hagander mag...@hagander.net writes:
If anything, I think the default should be default, and then we have
that map out to something. Because once you've initdb'ed, the config
file wil be stuck with a default and we can't change that in a minor
release *if* something like POODLE shows up
David Rowley dgrowle...@gmail.com writes:
On Sat, Oct 18, 2014 at 1:39 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Not sure how we get there without writing our own diff engine though :-(.
(Note that after a bit of looking around, it seems like it might not be
that hard to do something like this in
Robert Haas robertmh...@gmail.com writes:
But TBH I suspect 95% of the problems here would vanish if smart
shutdown weren't the default ...
But for your repeated objections, we would have changed the default to fast
years ago. AFAICT everyone else is in favor of that.
I've certainly
On 2014-10-19 12:26:24 -0400, Tom Lane wrote:
David Rowley dgrowle...@gmail.com writes:
On Sat, Oct 18, 2014 at 1:39 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Not sure how we get there without writing our own diff engine though :-(.
(Note that after a bit of looking around, it seems like it
Andres Freund and...@2ndquadrant.com writes:
I still think that reducing the need for having to do this is a good
idea, having to manually edit regression output to add regexes will be a
PITA.
Yeah :-(. We already have two features somewhat related to this, viz
prototype expected files in
On 2014-10-18 21:36:48 -0500, Jim Nasby wrote:
On 10/9/14, 4:19 PM, Andres Freund wrote:
On 2014-10-09 18:16:46 -0300, Alvaro Herrera wrote:
Andres Freund wrote:
On 2014-10-09 18:03:00 -0300, Alvaro Herrera wrote:
Bruce Momjian wrote:
I agree this is a serious problem. We have
Andres Freund and...@2ndquadrant.com writes:
There's rub here though. We unconditionally do:
/* Do post-vacuum cleanup and statistics update for each index */
for (i = 0; i nindexes; i++)
lazy_cleanup_index(Irel[i], indstats[i], vacrelstats);
and that's not
On 2014-10-19 12:50:30 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
There's rub here though. We unconditionally do:
/* Do post-vacuum cleanup and statistics update for each index */
for (i = 0; i nindexes; i++)
lazy_cleanup_index(Irel[i],
On 2014-10-19 12:38:52 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
I still think that reducing the need for having to do this is a good
idea, having to manually edit regression output to add regexes will be a
PITA.
Yeah :-(.
With regard to what triggered this
Once again, many thanks for the review. Here's a new version. I have
added operator classes for int8, text, and actually everything that btree
supports except:
bool
record
oidvector
anyarray
tsvector
tsquery
jsonb
range
since I'm not sure that it
On Sun, Oct 19, 2014 at 6:17 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
If anything, I think the default should be default, and then we have
that map out to something. Because once you've initdb'ed, the config
file wil be stuck with a default and we
On 10/16/2014 11:34 PM, Craig Ringer wrote:
Given the generally positive reception to this, here's a patch.
The first patch adds an errhint_log , akin to the current errdetail_log,
so we can send a different HINT to the server log than we do to the client.
The patch behaves as you describe.
Buildfarm member hamerkop has been failing in the pg_upgrade regression
test for the last several days. The problem looks like this:
command:
C:/buildfarm/build_root/HEAD/pgsql.build/contrib/pg_upgrade/tmp_check/install/bin/pg_restore
--port 50432 --username Administrator --exit-on-error
Jim Nasby jim.na...@bluetreble.com writes:
On 10/17/14, 10:16 PM, Tom Lane wrote:
BTW, on re-reading that code I notice that it will happily seize upon
the first suitable index (first in OID order), regardless of how many
lower-order columns that index has got. This doesn't make any
Magnus Hagander mag...@hagander.net writes:
On Sun, Oct 19, 2014 at 6:17 PM, Tom Lane t...@sss.pgh.pa.us wrote:
And in the end, if we set values like this from PG --- whether
hard-wired or via a GUC --- the SSL library people will have exactly
the same perspective with regards to *our* values.
On Oct 19, 2014 9:18 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Sun, Oct 19, 2014 at 6:17 PM, Tom Lane t...@sss.pgh.pa.us wrote:
And in the end, if we set values like this from PG --- whether
hard-wired or via a GUC --- the SSL library people will
Hi,
Commit 32984d8fc3dbb90a3fafb69fece0134f1ea790f9 forgot to change the
filename in the comment in contrib/pgcrypto/pgcrypto--1.2.sql. Trivial
patch attached.
.marko
*** a/contrib/pgcrypto/pgcrypto--1.2.sql
--- b/contrib/pgcrypto/pgcrypto--1.2.sql
***
*** 1,4
! /*
Hi,
On 10/17/14, 9:56 PM, Jeff Janes wrote:
This patch needs a rebase now that the armor header patch has been
committed.
Thanks. Will fix that shortly.
I'm guessing there's no need to bump the pgcrypto version to 1.3, since
there hasn't been a release with the 1.2 version?
.marko
--
On Thu, Oct 16, 2014 at 8:00 PM, Peter Geoghegan p...@heroku.com wrote:
Basically, it's difficult to make this work for technical reasons
precisely because what I have here isn't join-like. Can I easily
disallow OLD.* in a RETURNING clause (recall that we only project
inserted tuples, as
On Mon, Oct 20, 2014 at 6:27 AM, Marko Tiikkaja ma...@joh.to wrote:
I'm guessing there's no need to bump the pgcrypto version to 1.3, since
there hasn't been a release with the 1.2 version?
Yep. One version bump by major release is fine for a contrib module.
--
Michael
On Sun, Oct 19, 2014 at 2:52 PM, Greg Stark st...@mit.edu wrote:
Well OLD and NEW are also not joins yet we expose them this way. It
always seemed like a hack to me but better one hack than two different
inconsistent hacks, no?
In my opinion, no. Those hacks do not appear in the parse analysis
On Sun, Oct 19, 2014 at 1:02 PM, Sawada Masahiko sawada.m...@gmail.com
wrote:
On Fri, Oct 17, 2014 at 4:32 AM, Fabrízio de Royes Mello
fabriziome...@gmail.com wrote:
On Wed, Oct 15, 2014 at 11:41 AM, Sawada Masahiko sawada.m...@gmail.com
wrote:
On Mon, Oct 13, 2014 at 11:16 PM, Robert
On Sun, Oct 19, 2014 at 10:37 PM, Fabrízio de Royes Mello
fabriziome...@gmail.com wrote:
On Sun, Oct 19, 2014 at 1:02 PM, Sawada Masahiko sawada.m...@gmail.com
wrote:
On Fri, Oct 17, 2014 at 4:32 AM, Fabrízio de Royes Mello
fabriziome...@gmail.com wrote:
On Wed, Oct 15, 2014 at 11:41
On 10/19/14, 11:41 AM, Andres Freund wrote:
On 2014-10-18 21:36:48 -0500, Jim Nasby wrote:
On 10/9/14, 4:19 PM, Andres Freund wrote:
On 2014-10-09 18:16:46 -0300, Alvaro Herrera wrote:
Andres Freund wrote:
On 2014-10-09 18:03:00 -0300, Alvaro Herrera wrote:
Bruce Momjian wrote:
I agree
On 10/19/14, 2:09 PM, Tom Lane wrote:
Yeah, perhaps. I'd been wondering about adding a tie-breaking rule,
but that's a much simpler way to think about it. OTOH, that approach
could result in some instability in the choice of index: if you've got
both (field_we_care_about, some_int_field) and
Currently, a non-freeze vacuum will punt on any page it can't get a cleanup
lock on, with no retry. Presumably this should be a rare occurrence, but I
think it's bad that we just assume that and won't warn the user if something
bad is going on.
My thought is that if we skip any pages
34 matches
Mail list logo
