Dean == Dean Rasheed dean.a.rash...@gmail.com writes:
Maybe INT8 would be a better choice than INT4? But I'm not sure
there's any practical use-case for more than 30 grouping sets
anyway. Keep in mind the actual output volume probably grows like
2^N.
Dean Actually using ROLLUP the
On 20 May 2015 at 19:41, Tom Lane t...@sss.pgh.pa.us wrote:
David Fetter da...@fetter.org writes:
While kicking the tires on the new GROUPING() feature, I noticed that
NUMERIC has no cast to bit(n). GROUPING() produces essentially a
bitmap, although the standard mandates for some reason that
On Mon, Mar 16, 2015 at 11:05 PM, Jeff Janes jeff.ja...@gmail.com wrote:
On Mon, Feb 23, 2015 at 8:56 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Everyone seems to be happy with the names and behaviour of the GUCs, so
committed.
The docs suggest that max_wal_size will be
On Wed, May 20, 2015 at 5:21 PM, Robert Haas robertmh...@gmail.com wrote:
Please don't be discouraged here. Contributing to the PostgreSQL
community can be frustrating when you don't get what you want, and
even though I have been a member of this community for about 7 years
now and am a
On 21 May 2015 at 14:25, Peter Geoghegan p...@heroku.com wrote:
If I have two constraints and I think about it, I would want to be able
to
specify this...
INSERT
ON CONFLICT (col1) DO UPDATE... (handle it one way)
ON CONFLICT (col2) DO UPDATE... (handle it 2nd way)
but I cannot
On Thu, May 21, 2015 at 12:24:03PM -0400, Robert Haas wrote:
On Thu, May 21, 2015 at 12:21 PM, Andrew Gierth
and...@tao11.riddles.org.uk wrote:
David == David Fetter da...@fetter.org writes:
David How about a more sensible data structure as a PG-specific addon.
David GROUPING_JSON()
Feng Tian ft...@vitessedata.com writes:
Here is a query, server was built witch GCC on Linux, AMD64.
ftian=# select 1.5::int, 1.5::double precision::int, 314.5::int,
314.5::double precision::int;
int4 | int4 | int4 | int4
--+--+--+--
2 |2 | 315 | 314
(1 row)
I
On Thu, May 21, 2015 at 9:51 AM, Simon Riggs si...@2ndquadrant.com wrote:
No not all, but we can evaluate the constraints one at a time in a
consistent order.
We do so currently. Now, you point out that that might not be the most
useful ordering, and as it happens I agree. But changing that
Hi, Hackers,
Here is a query, server was built witch GCC on Linux, AMD64.
ftian=#
ftian=# select 1.5::int, 1.5::double precision::int, 314.5::int,
314.5::double precision::int;
int4 | int4 | int4 | int4
--+--+--+--
2 |2 | 315 | 314
(1 row)
I believe this is because
G'Day guys,
after exploiting all the other sources, I've reached the point where I
need to use this final option to get some help.
We are trying to setup Postgres with TLSv1.2 (undergoing PA:DSS audit),
but getting a bit stuck there with Postgres reporting “could not accept
SSL connection:
On May 20, 2015, at 9:22 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andres Freund and...@anarazel.de writes:
You realize there's other instances of this in the same damn function?
Not to mention that several places in libpq/fe-exec.c should be
taught about this new tag. And who-knows-what in
On Tue, May 19, 2015 at 8:45 AM, Amit Kapila amit.kapil...@gmail.com wrote:
On Mon, May 11, 2015 at 3:00 AM, Robert Haas robertmh...@gmail.com wrote:
I think it might be better to try to solve this problem in a more
localized way. Can we arrange for planstate-instrumentation to point
I noticed that my patch to archive the last incomplete segment from old
timeline at promotion with the .partial suffix (de768844) was a few
bricks shy of a load. It makes a copy of the segment with the .partial
suffix, and it gets archived correctly, but it still leaves the segment
lying in
On Wed, May 20, 2015 at 8:46 PM, Andres Freund and...@anarazel.de wrote:
I've a hard time believing it's actually a good idea to change this. It
pretty much seems to only be useful if you're doing unqualified SELECT
pg_cancel_backend(pid) FROM pg_stat_activity; type queries. I don't see
that
On 21 May 2015 at 09:20, Andrew Gierth and...@tao11.riddles.org.uk wrote:
Dean == Dean Rasheed dean.a.rash...@gmail.com writes:
Maybe INT8 would be a better choice than INT4? But I'm not sure
there's any practical use-case for more than 30 grouping sets
anyway. Keep in mind the actual
On Mon, May 18, 2015 at 9:40 AM, Beena Emerson memissemer...@gmail.com wrote:
Er, I am not sure I follow here. The idea proposed was to define a
string formatted with some infra-language within the existing GUC
s_s_names.
I am sorry, I misunderstood. I thought the language approach meant use
Hello!
I'm willing to implement the 'Add support for interface/ipaddress binding
to libpq' feature from the ToDo list.
Actually, the 'ipaddress' part.
For this I'm planning to do the following:
- Introduce 'sourceaddr' parameter keyword and 'PGSOURCEADDR' env var
which can be used to specify
On 05/21/2015 05:08 AM, Peter Geoghegan wrote:
On Wed, May 20, 2015 at 6:22 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I am not really sure that it was a good idea to invent
this command tag. In fact, I'm pretty sure it was a *bad* idea ---
what will happen if we ever create a statement actually
I wonder why pg_basebackup doesn't have any support for replication slots.
When relying on replication slots to hang on to WAL data, there is a gap
between when pg_basebackup finishes and streaming replication is started
where WAL data could be thrown away by the primary.
Looking at the code,
I wrote:
But BlockIdData is laid out and accessed as two 16-bit fields, so there
should be no problem. On what platform exactly do you see a failure?
Ah, after reading the gcc manual a bit more closely, I get the point.
For some reason I think we assumed that packed would not result in
On Thu, May 21, 2015 at 1:15 PM, Simon Riggs si...@2ndquadrant.com wrote:
OK, let me summarise. First, thanks for putting time into this feature; we
all wish to see it work and work well.
You're welcome.
The current ON CONFLICT syntax requires us to specify one-and-only-one
On 21 May 2015 at 15:44, Peter Geoghegan p...@heroku.com wrote:
Please look at the $SUBJECT of this thread. We're here now.
What do you want me to do about it? I've said that I think that what
you say about not mandating the inference clause in the parser could
be okay. If you want to
On Thu, May 21, 2015 at 1:50 PM, Simon Riggs si...@2ndquadrant.com wrote:
(There is no try)
CREATE TABLE customers
(username TEXT PRIMARY KEY
,email TEXT UNIQUE
,billing NUMERIC(11,2)
);
1. INSERT INTO customers VALUES ('sriggs', 'si...@2ndquadrant.com', 10.0);
2. INSERT INTO customers
I wrote:
Heikki Linnakangas hlinn...@iki.fi writes:
I think that trying to find the equivalence member in
create_index_scan() is too fragile.
I agree; will contemplate how to do this better.
I think probably what we ought to do here is just use exprType() of the
ORDER BY expression. There
Paul Ramsey pram...@cleverelephant.ca writes:
I'm implementing the recheck functionality for PostGIS so we can
support it when 9.5 comes out, and came across this fun little
crasher.
Should be fixed as of git tip. Thanks for the report!
regards, tom lane
--
Sent
Alvaro Herrera wrote:
That said, I'm not sure about having it be the same, either: first, I
don't think we need to update the fe-exec.c code at all -- I mean, all
the things I see there are very old compatibility stuff;
(But as I said earlier, it doesn't really affect me either way, so feel
Andres Freund wrote:
On 2015-05-20 21:22:08 -0400, Tom Lane wrote:
Not to mention that several places in libpq/fe-exec.c should be
taught about this new tag. And who-knows-what in other client-side
libraries. I am not really sure that it was a good idea to invent
this command tag. In
On Thu, May 21, 2015 at 4:32 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
(But as I said earlier, it doesn't really affect me either way, so feel
free to rip it out.)
That appears to be the consensus. Should I post a patch?
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list
I wrote:
I think this was probably a mistake. I suggest that in the back branches
we should leave the server alone (rejecting SSL v3 might annoy somebody
using old non-libpq clients) but adjust libpq to use SSLv23_method() plus
SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3. IOW, back-patch
On 2015-05-21 20:28:41 -0300, Alvaro Herrera wrote:
That said, I'm not sure about having it be the same, either: first, I
don't think we need to update the fe-exec.c code at all -- I mean, all
the things I see there are very old compatibility stuff; reporting the
OID of the just-inserted row?
Ah, thanks! I did not realize numeric comes into play. But, this is even
more interesting -- I would expect numeric is more consistent than
float/double when dealing with stuff like rounding.
I missed the not too long ago discussion, :-) Regardless of the
mechanisms underneath, it would be
David Fetter da...@fetter.org writes:
Also is there a really great reason that bitwise operations don't work
on NUMERIC? Lack of tuits is a good reason, but not, it seems to me,
a great one.
Not sure that bitwise operations make too much sense on values that
are (a) possibly fractional and
On Thu, May 21, 2015 at 11:55 AM, Simon Riggs si...@2ndquadrant.com wrote:
It seems strange to force the user to think about constraint handling
and
then not offer them any choices once they have done the thinking.
What if both constraints are violated? Won't the update end up in trouble?
[Sorry for being late to the party, travelling does take away too much
time sometimes.]
On 19.05.2015 21:04, Greg Sabino Mullane wrote:
Bruno Harbulot asked for a devil's advocate by saying:
My main point was that this is not specific to JDBC. Considering that even
PostgreSQL's own ECPG is
* Simon Riggs (si...@2ndquadrant.com) wrote:
On 21 May 2015 at 14:25, Peter Geoghegan p...@heroku.com wrote:
If the update is the same no matter which constraint is violated, why
would
I need to specify the constraint? We're forcing the developer to make an
arbitrary choice between two
On 2015-05-21 15:34:00 -0400, Tom Lane wrote:
Piotr Stefaniak postg...@piotr-stefaniak.me writes:
But due to how ExecRowMark struct is laid out in memory, the packed
struct ItemPointerData begins at an uneven offset, leading to misaligned
access whenever BlockIdData is set by
Piotr Stefaniak postg...@piotr-stefaniak.me writes:
But due to how ExecRowMark struct is laid out in memory, the packed
struct ItemPointerData begins at an uneven offset, leading to misaligned
access whenever BlockIdData is set by ItemPointerSetInvalid() (and
likely in some other places,
available as soon as 9.6 came out. But from the perspective of a driver
author who has to support queries written by other people, the problem
would not be gone for at least ten years more. Changing the driver's
behavior sounds like a more practical solution.
Even if it means breaking the
I'm implementing the recheck functionality for PostGIS so we can
support it when 9.5 comes out, and came across this fun little
crasher.
This works:
select id, name from geonames order by geom -
'SRID=4326;POINT(-75.6163 39.746)'::geometry limit 10;
This crashes (just reversing the argument
On 19 May 2015 at 19:59, Peter Geoghegan p...@heroku.com wrote:
On Tue, May 19, 2015 at 2:28 PM, Simon Riggs si...@2ndquadrant.com
wrote:
On 19 May 2015 at 17:10, Peter Geoghegan p...@heroku.com wrote:
On Tue, May 19, 2015 at 1:57 PM, Simon Riggs si...@2ndquadrant.com
wrote:
We
On 20 May 2015 at 05:49, Geoff Winkless pgsqlad...@geoff.dj wrote:
On 19 May 2015 at 21:57, Simon Riggs si...@2ndquadrant.com wrote:
It's not clear to me how a single INSERT could cause two or more UPDATEs.
CREATE TABLE mytable (
c1 int NOT NULL,
c2 int NOT NULL,
PRIMARY KEY
On Thu, May 21, 2015 at 12:21 PM, Andrew Gierth
and...@tao11.riddles.org.uk wrote:
David == David Fetter da...@fetter.org writes:
David How about a more sensible data structure as a PG-specific addon.
David GROUPING_JSON() seems like just the thing.
What exactly do you think it should
On 21 May 2015 at 17:15, David Fetter da...@fetter.org wrote:
On Thu, May 21, 2015 at 04:19:27PM +0100, Andrew Gierth wrote:
Dean == Dean Rasheed dean.a.rash...@gmail.com writes:
Consider that in both MSSQL 2014 and Oracle 12 the limit on the number
of arguments in a GROUPING()
Andres == Andres Freund and...@anarazel.de writes:
Andres I'd vote for either 0) do nothing or 1). I think the use case
Andres for specifying 64+ (or even 32+) columns in grouping is pretty
Andres darn slim. And as you said, it's not that hard to work around
Andres it if you need it, and
On 22/05/15 02:06, Tom Lane wrote:
Jan Bilek jan.bi...@eftlab.co.uk writes:
We are trying to setup Postgres with TLSv1.2 (undergoing PA:DSS audit),
but getting a bit stuck there with Postgres reporting “could not accept
SSL connection: no shared cipher�. This is obviously an internal
I wrote:
libpq versions before 9.4 will only accept TLSv1 exactly. In 9.4 it
should negotiate the highest TLS version supported by both server and
client.
I don't recall why we didn't back-patch that change, probably excessive
concern for backwards compatibility ... but anyway, AFAICS from
On Mon, May 18, 2015 at 4:03 AM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp wrote:
On 2015/05/16 3:32, Robert Haas wrote:
On Thu, May 14, 2015 at 6:37 AM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp wrote:
On second thought, I noticed that as for this option, we cannot live
without
allowing
On Thu, May 21, 2015 at 04:19:27PM +0100, Andrew Gierth wrote:
Dean == Dean Rasheed dean.a.rash...@gmail.com writes:
Consider that in both MSSQL 2014 and Oracle 12 the limit on the number
of arguments in a GROUPING() expression is ... 1.
Dean Actually Oracle haven't quite followed
David == David Fetter da...@fetter.org writes:
David How about a more sensible data structure as a PG-specific addon.
David GROUPING_JSON() seems like just the thing.
What exactly do you think it should return?
--
Andrew (irc:RhodiumToad)
--
Sent via pgsql-hackers mailing list
49 matches
Mail list logo
