* Peter Eisentraut wrote:
On 5/16/15 12:06 PM, Tom Lane wrote:
As exhibited for instance here:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=spoonbill&dt=2015-05-16%2011%3A00%3A07
I've been able to replicate this on a Fedora 21 box: works fine with
Python 2, fails with Python 3. See
On Fri, May 22, 2015 at 5:52 AM, Piotr Gasidło wrote:
> Got strange problem. Unable to repeat, but got logs.
>
> Simple master-slave using streaming replication.
> Master is running. Slave is down.
> Segment 00044C4D0090 was successfully archived and send
> from master to slave.
>
> No
If you do the following sequence, the server gives the least helpful error
message:
initdb data
pg_ctl -D data -l logfile start
# The following reconfigs are obvious based on error message if you try to take
a base backup
echo 'local replication all trust’ >> data/pg_hba.conf
sed -i 's/
Robert Haas wrote:
> On Fri, May 15, 2015 at 4:15 PM, Alvaro Herrera
> wrote:
> >> Really? I was thinking of the test code as throwaway. I just wanted
> >> to fix the bug.
> >
> > Oh, that's fine then. I thought you wanted to push it.
>
> Nah, sorry, I shoulda been more clear about that. That
On 2015/05/22 1:36, Robert Haas wrote:
On Mon, May 18, 2015 at 4:03 AM, Etsuro Fujita
wrote:
On 2015/05/16 3:32, Robert Haas wrote:
On Thu, May 14, 2015 at 6:37 AM, Etsuro Fujita
wrote:
On second thought, I noticed that as for this option, we cannot live
without
allowing IMPORT FOREIGN SCHE
On 2015/05/22 0:45, Robert Haas wrote:
On Fri, May 15, 2015 at 3:15 AM, Etsuro Fujita
wrote:
Here is a patch to improve the ALTER FOREIGN TABLE documentation a bit:
(1) fix markup for ADD table_constraint [ NOT VALID ] and (2) remove an
unnecessary comma from an example query.
As usual, good
> > One thing tricky is "peusdo projection" which is done by
> > deparseProjectionSql for whole-row reference. This is done by put the
> > query string in FROM subquery and add whole-row reference in outer
> > SELECT clause. This is done by ExecProjection in 9.4 and older, but
> > we need to do t
On Mon, May 18, 2015 at 10:58:42AM -0400, Bruce Momjian wrote:
> On Sat, May 16, 2015 at 12:21:12PM -0400, Noah Misch wrote:
> > The rest of this change is opaque to me. "More consistent" with what? The
> > old use of the "tli" variable sure looked like a bug, considering the
> > variable
> > wa
On Thu, May 21, 2015 at 5:48 PM, Andres Freund wrote:
>
>> If the number is useful, then perhaps we should distinguish the cases;
>> and if it's not useful, why not just return zero?
>
> There's libraries/frameworks checking if an insert succeeded by looking
> at that number, and it seems like a b
On 22/05/15 10:45, Tom Lane wrote:
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_SSLv
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 ro
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 820f08cabd
Paul Ramsey 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 via pgsql-hackers mailing
On Thu, May 21, 2015 at 4:32 PM, Alvaro Herrera
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 (pgsql-hackers@postgresql
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 ta
I wrote:
> Heikki Linnakangas 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 are opclas
On Thu, May 21, 2015 at 1:50 PM, Simon Riggs 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 VALUES ('s
On Fri, May 22, 2015 at 4:33 AM, Feng Tian wrote:
> 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, :
On 05/21/2015 10:15 AM, Robert Haas wrote:
On Wed, May 20, 2015 at 3:42 PM, Andres Freund wrote:
On 2015-05-20 15:37:15 -0400, Tom Lane wrote:
Josh Berkus writes:
That does cover all bases, and users would be able to create the
operator which suits their particular use case easily. It's al
Heikki Linnakangas writes:
> The find_ec_member_for_expr() call in create_indexscan_plan() fails to
> find the equivalence member for the path key.
> match_clause_to_ordering_op() found the match by commuting the operator,
> but code in create_indexscan_plan() doesn't take that into account.
R
Andres Freund writes:
> On 2015-05-21 16:49:27 -0400, Tom Lane wrote:
>> I considered also adding a Static_assert about sizeof(ItemIdData),
>> but I'm afraid that compilers that don't support these pragmas
>> probably don't support Static_assert either, so it's not clear
>> that that would catch a
Piotr Stefaniak writes:
> On 05/21/2015 10:08 PM, Tom Lane wrote:
>> It's not clear to me whether all compilers that accept "packed" also
>> accept "aligned", but there are enough ARM machines in the buildfarm
>> that we could hope that we'll find out if this isn't portable.
> I think src/include
On 21 May 2015 21:15, "Simon Riggs" wrote:
> I would like to see this happen now before we get hit with usage
questions similar to OP's. If both requests cannot happen now, if we can at
least agree a path for future enhancement we can refer people to what will
happen in later releases when they as
On 05/21/2015 11:28 PM, Tom Lane wrote:
Paul Ramsey 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.
Hmm, works in 9.3 and 9.4, so it's been broken recently.
It was clearly broken by knn-with-rec
On 2015-05-21 16:49:27 -0400, Tom Lane wrote:
> I considered also adding a Static_assert about sizeof(ItemIdData),
> but I'm afraid that compilers that don't support these pragmas
> probably don't support Static_assert either, so it's not clear
> that that would catch anything.
I think your fallba
On 21 May 2015 at 16:27, Peter Geoghegan wrote:
> Try and convince me.
>
(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 VALU
Andrew Dunstan writes:
> On 05/21/2015 04:08 PM, Tom Lane wrote:
>> I wonder whether we should drop the ARM assumption and instead write
>>
>> #if defined(pg_attribute_packed) && defined(pg_attribute_aligned)
>> pg_attribute_packed()
>> pg_attribute_aligned(2)
>> #endif
>>
>> so that the annotat
On Thu, May 21, 2015 at 1:27 PM, Peter Geoghegan wrote:
>> As the patch author I hope and expect that you will listen to this and
>> consider how you will resolve these problems, just as any of us has done
>> when they are the patch author, even after commit. I would like to see this
>> happen now
On 05/21/2015 04:08 PM, Tom Lane wrote:
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 assume
Paul Ramsey 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.
Hmm, works in 9.3 and 9.4, so it's been broken recently.
Will look, thanks!
regards, tom lane
--
Sent via
On Thu, May 21, 2015 at 1:15 PM, Simon Riggs 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
> conflict_target/conflict_action pai
On 21 May 2015 at 15:44, Peter Geoghegan 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 change it, obv
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
misa
On 2015-05-21 15:34:00 -0400, Tom Lane wrote:
> Piotr Stefaniak 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
> >
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 or
[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
On Thu, May 21, 2015 at 11:55 AM, Simon Riggs 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?
>
>
> Gre
> 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 th
* Simon Riggs (si...@2ndquadrant.com) wrote:
> On 21 May 2015 at 14:25, Peter Geoghegan 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 con
Piotr Stefaniak 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, too).
But BlockIdData is
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 qu
David Fetter 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 (b) inherently d
Feng Tian 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 believe this i
On 21 May 2015 at 14:25, Peter Geoghegan 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 canno
On Thu, May 21, 2015 at 12:24:03PM -0400, Robert Haas wrote:
> On Thu, May 21, 2015 at 12:21 PM, Andrew Gierth
> wrote:
> >> "David" == David Fetter writes:
> >
> > David> How about a more sensible data structure as a PG-specific addon.
> > David> GROUPING_JSON() seems like just the thing.
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 r
On Thu, May 21, 2015 at 9:51 AM, Simon Riggs 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 ordering
to not just be
On 20 May 2015 at 05:49, Geoff Winkless wrote:
> On 19 May 2015 at 21:57, Simon Riggs 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 (c1),
> UNIQUE (c2)
>
> );
>
On 19 May 2015 at 19:59, Peter Geoghegan wrote:
> On Tue, May 19, 2015 at 2:28 PM, Simon Riggs
> wrote:
> > On 19 May 2015 at 17:10, Peter Geoghegan wrote:
> >>
> >> On Tue, May 19, 2015 at 1:57 PM, Simon Riggs
> >> wrote:
> >> > We should allow DO UPDATE to exclude a constraint and apply a
>
On Mon, May 18, 2015 at 4:03 AM, Etsuro Fujita
wrote:
> On 2015/05/16 3:32, Robert Haas wrote:
>> On Thu, May 14, 2015 at 6:37 AM, Etsuro Fujita
>> wrote:
>>>
>>> On second thought, I noticed that as for this option, we cannot live
>>> without
>>> allowing IMPORT FOREIGN SCHEMA to return ALTER FO
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 f
On 22/05/15 02:06, Tom Lane wrote:
Jan Bilek 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 OpenSSL
message, but worryin
> "Andres" == Andres Freund 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 that's only
On 21 May 2015 at 17:15, David Fetter wrote:
> On Thu, May 21, 2015 at 04:19:27PM +0100, Andrew Gierth wrote:
>> > "Dean" == Dean Rasheed writes:
>>
>> >> Consider that in both MSSQL 2014 and Oracle 12 the limit on the number
>> >> of arguments in a GROUPING() expression is ... 1.
>>
>> De
On Thu, May 21, 2015 at 12:21 PM, Andrew Gierth
wrote:
>> "David" == David Fetter 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?
I vote for { "rube" : "g
> "David" == David Fetter 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 (pgsql-hackers@pos
On Thu, May 21, 2015 at 04:19:27PM +0100, Andrew Gierth wrote:
> > "Dean" == Dean Rasheed 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 the stand
Jan Bilek 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 OpenSSL
> message, but worrying part is that we've had thi
On 21 May 2015 at 02:53, Jeff Janes wrote:
> I think the old behavior, where restartpoints were driven only by time and
> not by volume, was a misfeature.
>
I have no objection to changing that. The main essence of that was to
ensure that a standby could act differently to a master, given diffe
On 2015-05-21 16:19:27 +0100, Andrew Gierth wrote:
> True. It can handle more than 128 bits, even - I gave up trying after that.
>
> So. Options:
>
> 1) change GROUPING() to return bigint and otherwise leave it as is.
>
> 2) change GROUPING() to return numeric.
>
> 3) change GROUPING() so that
On Fri, May 15, 2015 at 3:15 AM, Etsuro Fujita
wrote:
> Here is a patch to improve the ALTER FOREIGN TABLE documentation a bit:
> (1) fix markup for ADD table_constraint [ NOT VALID ] and (2) remove an
> unnecessary comma from an example query.
As usual, good catch. Committed.
--
Robert Haas
E
Andrew Gierth writes:
> So. Options:
> 1) change GROUPING() to return bigint and otherwise leave it as is.
> 2) change GROUPING() to return numeric.
> 3) change GROUPING() so that the result type varies with the number of
> args. I don't see anything in the spec that actually forbids this - it
On Thu, May 21, 2015 at 3:53 PM, Jeff Janes wrote:
> On Mon, Mar 16, 2015 at 11:05 PM, Jeff Janes wrote:
>>
>> On Mon, Feb 23, 2015 at 8:56 AM, Heikki Linnakangas
>> wrote:
>>>
>>>
>>> Everyone seems to be happy with the names and behaviour of the GUCs, so
>>> committed.
>>
>>
>>
>> The docs sug
> "Dean" == Dean Rasheed 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 the standard. They have 2
Dean> separate functions: GROUPING() which only allows 1
On Wed, May 20, 2015 at 12:58 AM, Chris Rogers wrote:
> I need this feature a lot. Can anyone point me to a place in the code where
> I can hack together a quick-and-dirty, compatibility-breaking
> implementation? Thanks!
Does this help?
http://www.postgresql.org/message-id/38448.1430519...@ss
Pavel Stehule writes:
>
> 2015-03-23 17:11 GMT+01:00 Pavel Stehule :
>
>> Hi
>>
>> 2015-03-15 16:09 GMT+01:00 Tom Lane :
>>
>>> Pavel Stehule writes:
>>> > other variant, I hope better than previous. We can introduce new long
>>> > option "--strict". With this active option, every pattern specifi
On Wed, May 20, 2015 at 3:42 PM, Andres Freund wrote:
> On 2015-05-20 15:37:15 -0400, Tom Lane wrote:
>> Josh Berkus writes:
>> > That does cover all bases, and users would be able to create the
>> > operator which suits their particular use case easily. It's also fairly
>> > similar to how jsqu
On Sat, May 16, 2015 at 9:04 AM, Shigeru Hanada
wrote:
> d) All relations must have the same effective user id
> This check is done with userid stored in PgFdwRelationInfo, which is
> valid only when underlying relations have the same effective user id.
> Here "effective user id" means id of the u
On 05/21/2015 03:42 PM, Peter Eisentraut wrote:
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 thr
On Mon, May 18, 2015 at 9:40 AM, Beena Emerson 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 of
> hooks an
On 05/21/2015 05:08 AM, Peter Geoghegan wrote:
On Wed, May 20, 2015 at 6:22 PM, Tom Lane 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 named UPSERT?
Why
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, the
On Tue, May 19, 2015 at 8:45 AM, Amit Kapila wrote:
> On Mon, May 11, 2015 at 3:00 AM, Robert Haas 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
>> directory into the DSM, instead of copying th
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 pg_
On 21 May 2015 at 09:20, Andrew Gierth wrote:
>> "Dean" == Dean Rasheed 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
On Wed, May 20, 2015 at 8:46 PM, Andres Freund 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 as something we
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 May 20, 2015, at 9:22 PM, Tom Lane wrote:
> Andres Freund 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 other client-side
> libraries. I
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: n
On Wed, May 20, 2015 at 5:21 PM, Robert Haas 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 major contributor an
> "Dean" == Dean Rasheed 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 output volu
On 20 May 2015 at 19:41, Tom Lane wrote:
> David Fetter 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 it be a
>> numeric type.
>
>
83 matches
Mail list logo
