On Fri, Apr 25, 2014 at 4:47 PM, Paul Ramsey wrote:
> Is it possible to make custom types hashable? There's no hook in the
> CREATE TYPE call for a hash function, but can one be hooked up
> somewhere else? In an operator?
See 35.14.6., System Dependencies on Operator Classes
--
Peter Geoghegan
When trying to write a recursive CTE using the PostGIS geometry type,
I was told this:
ERROR: could not implement recursive UNION
DETAIL: All column datatypes must be hashable.
Is it possible to make custom types hashable? There's no hook in the
CREATE TYPE call for a hash function, but can one
Hi,
Currently the maximum for max_connections (+ bgworkers + autovacuum) is
defined by
#define MAX_BACKENDS0x7f
which unfortunately means that some things like buffer reference counts
need a full integer to store references.
Since there's absolutely no sensible scenario for setting
max_co
On 2014-04-24 23:28:14 +0200, Andres Freund wrote:
> On 2014-04-24 12:43:13 -0400, Tom Lane wrote:
> > Andres Freund writes:
> > > On 2014-04-24 11:02:44 -0400, Tom Lane wrote:
> > >> FWIW, I like the LWLockAssignBatch idea a lot better than the currently
> > >> proposed patch. LWLockAssign is a
On 2014-04-25 17:19:00 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-04-25 17:05:26 -0400, Tom Lane wrote:
> >> I think this is just a hangover from
> >> before we paid much attention to expression typmods at all, and
> >> propose the attached patch.
>
> > Any chance it could cause p
Tomas Vondra writes:
> On 23.4.2014 16:07, Tom Lane wrote:
>> To be concrete: let's add a new boolean parameter with the semantics
>> of "final function takes extra dummy arguments" (default false).
>> There would need to be one for the separate moving-aggregate final
>> function too, of course.
Andres Freund writes:
> On 2014-04-25 17:05:26 -0400, Tom Lane wrote:
>> I think this is just a hangover from
>> before we paid much attention to expression typmods at all, and
>> propose the attached patch.
> Any chance it could cause problems with stored trees being different
> from newly gener
On 23.4.2014 16:07, Tom Lane wrote:
>
> To be concrete: let's add a new boolean parameter with the semantics
> of "final function takes extra dummy arguments" (default false).
> There would need to be one for the separate moving-aggregate final
> function too, of course.
>
> The best naming idea I
Hi,
On 2014-04-25 17:05:26 -0400, Tom Lane wrote:
> A Salesforce colleague asked me why, for something like
>
> the index column ends up as "bpchar" and not "char(15)". The CASE
> expression does get resolved as char(15), but it turns out that
> index.c just ignores that.
I've seen that bef
A Salesforce colleague asked me why, for something like
regression=# create table foo1 (f1 char(15), f2 char(15));
CREATE TABLE
regression=# create index on foo1((case when f1>'z' then f1 else f2 end));
CREATE INDEX
regression=# \d foo1_f2_idx
Index "public.foo1_f2_idx"
Column | Typ
Greetings,
As some may be aware, we are currently working with Rackspace to
upgrade the PostgreSQL infrastructure systems which they graciously
host for us. As part of these upgrades there will be downtime for
systems hosted there.
Our first planned downtime will be for ~ 2 hours on Mo
(more fruit from my little page-image-comparison hack)
WAL replay of filling a GIN fast list page is a bit funky. I believe
there are two bugs in it, but they're both harmless:
writeListPage function initializes the page, and adds a bunch of tuples
to it. All the tuples are included in the WA
2014-04-24 15:19 keltezéssel, Boszormenyi Zoltan írta:
2014-04-24 14:50 keltezéssel, Michael Meskes írta:
Thanks an awful lot Antonin.
Committer availability might well be the issue, but missing review
probably too.
Yes, you're right. If my taks is mostly one last glance and a commit I will ma
On Fri, Apr 25, 2014 at 10:58:29AM -0700, Josh Berkus wrote:
> On 04/24/2014 05:23 PM, Marti Raudsepp wrote:
> > On Thu, Apr 24, 2014 at 8:40 PM, Josh Berkus wrote:
> >> A pseudo-random UUID is frankly pretty
> >> useless to me because (a) it's not really unique
> >
> > This is FUD. A pseudorando
On 04/24/2014 05:23 PM, Marti Raudsepp wrote:
> On Thu, Apr 24, 2014 at 8:40 PM, Josh Berkus wrote:
>> A pseudo-random UUID is frankly pretty
>> useless to me because (a) it's not really unique
>
> This is FUD. A pseudorandom UUID contains 122 bits of randomness. As
> long as you can trust the ra
I've now done a non-limited comparative benchmark of master against
the patch (once again, with usage_count starting at 6, and
BM_MAX_USAGE_COUNT at 30) with a Gaussian distribution. Once again,
the distribution threshold used was consistently 5.0, causing the
patched pgbench to report for each tes
On 2014-04-25 18:25:44 +0200, Andres Freund wrote:
> On 2014-04-25 12:05:17 -0400, Tom Lane wrote:
> > Andres Freund writes:
> > > The case I am worried most about is queries like:
> > > SELECT a, b FROM f WHERE f > ROW(38, 'whatever') ORDER BY f;
> > > I've seen such generated by a some query gen
On 2014-04-25 12:05:17 -0400, Tom Lane wrote:
> Andres Freund writes:
> > The case I am worried most about is queries like:
> > SELECT a, b FROM f WHERE f > ROW(38, 'whatever') ORDER BY f;
> > I've seen such generated by a some query generators for paging. But I
> > guess that's something we're go
Andres Freund writes:
> The case I am worried most about is queries like:
> SELECT a, b FROM f WHERE f > ROW(38, 'whatever') ORDER BY f;
> I've seen such generated by a some query generators for paging. But I
> guess that's something we're going to have to accept.
Meh ... is it likely that the co
On 2014-04-25 11:22:09 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-04-24 19:40:30 -0400, Tom Lane wrote:
> >> * Because HeapTupleGetDatum might allocate a new tuple, the wrong thing
> >> might happen if the caller changes CurrentMemoryContext between
> >> heap_form_tuple and HeapTup
Andres Freund writes:
> On 2014-04-24 19:40:30 -0400, Tom Lane wrote:
>> * Because HeapTupleGetDatum might allocate a new tuple, the wrong thing
>> might happen if the caller changes CurrentMemoryContext between
>> heap_form_tuple and HeapTupleGetDatum.
> It's fscking ugly to allocate memory in a
On Fri, Apr 25, 2014 at 1:43 AM, Marti Raudsepp wrote:
> Obviously you can't use random(). That's why I talked about
> cryptographic PRNGs, crypto libraries do proper seeding and generate
> reliably random numbers all the time.
The difficulty lies not really in the PRNG implementation (which is
Hi,
On 2014-04-24 19:40:30 -0400, Tom Lane wrote:
> * Because HeapTupleGetDatum might allocate a new tuple, the wrong thing
> might happen if the caller changes CurrentMemoryContext between
> heap_form_tuple and HeapTupleGetDatum.
It's fscking ugly to allocate memory in a PG_RETURN_... But I don'
Heikki Linnakangas writes:
> On 04/25/2014 02:40 AM, Tom Lane wrote:
>> * The patch changes HeapTupleGetDatum from a simple inline macro into
>> a function call. This means that third-party extensions will not get
>> protection against creation of toast-pointer-containing composite Datums
>> unti
>
> On second thought I noticed that that makes CREATE FOREIGN TABLE include
> an OID column in newly-created foreign tables wrongly, when the
> default_with_oids parameter is set to on. Please find attached a patch.
>
>
The fix makes sense to me, since in ALTER TABLE SET WITH OIDS we check that
t
>>> If your goal is to make this functionality available as soon as
possible to users, an external extension is the way to go.
No, my primary goal is to create the useful contrib extension and help to
the community =)
So, I also want to do it as a pgxn extension.
On 25 April 2014 00:11, Josh Berk
26 matches
Mail list logo
