Tom,
Hope this helps
>From the Oracle manual:
Purpose
Returns char1, left-padded to length n with the sequence of characters
in char2; char2 defaults to a single blank. If char1 is longer than n,
this function returns the portion of char1 that fits in n.
The argument n is the total length of th
) for nearest event processing.
The SQL command for sheduler deleting:
DELETE SHEDULER name
--
Best regards,
Paul Mamin mailto:[EMAIL PROTECTED]
---(end of broa
On Sun, Mar 13, 2016 at 7:31 PM, David Rowley
wrote:
> On 14 March 2016 at 14:52, James Sewell wrote:
>> One question - how is the upper limit of workers chosen?
>
> See create_parallel_paths() in allpaths.c. Basically the bigger the
> relation (in pages) the more workers will be allocated, up un
I spent some time over the weekend trying out the different modes of
parallel query (seq scan, aggregate, join) in combination with PostGIS
and have written up the results here:
http://blog.cleverelephant.ca/2016/03/parallel-postgis.html
The TL:DR; is basically
* With some adjustments to functio
On Mon, Mar 28, 2016 at 9:45 AM, Stephen Frost wrote:
> Paul,
>
> * Paul Ramsey (pram...@cleverelephant.ca) wrote:
>> I spent some time over the weekend trying out the different modes of
>> parallel query (seq scan, aggregate, join) in combination with PostGIS
>> and
On Mon, Mar 28, 2016 at 9:18 AM, Paul Ramsey wrote:
> Parallel join would be a huge win, so some help/pointers on figuring
> out why it's not coming into play when our gist operators are in
> effect would be helpful.
Robert, do you have any pointers on what I should look for to
> First, I beg to differ with this statement: "Some of the execution
> results output are wrong! " The point is that
> line has loops=4, so as in any other case where loops>1, you're seeing
> the number of rows divided by the number of loops. It is the
> *average* number of rows that were pro
On Tue, Mar 29, 2016 at 12:48 PM, Paul Ramsey wrote:
>> On the join case, I wonder if it's possible that _st_intersects is not
>> marked parallel-safe? If that's not the problem, I don't have a
>> second guess, but the thing to do would be to figure out whether
On Tue, Mar 29, 2016 at 1:14 PM, Robert Haas wrote:
> On Tue, Mar 29, 2016 at 3:48 PM, Paul Ramsey
> wrote:
>>> I have no idea why the cost adjustments that you need are different
>>> for the scan case and the aggregate case. That does seem problematic,
>>&g
I've been working through the expanded object code to try and get a
demonstration of it working with PostGIS (still having some problems,
but it's a learning experience). On an unrelated from, I noticed in
the array expanded code, that the array code is managing its own copy
of a cache of the flat
I'm starting to think this might not actually be my mistake, but be a
very narrow issue w/ the expanded object code.
So, I've added support for converting postgis in-memory objects into
expanded outputs, and have overwritten the usual
lwgeom_to_gserialized() function with one that creates an expan
papered over things so much that valgrind couldn’t see what
was going on under the covers.
Thanks!
P
> On Jan 18, 2016, at 8:36 AM, Tom Lane wrote:
>
> Paul Ramsey writes:
>> So, I've added support for converting postgis in-memory objects into
>> expanded outputs
Thank the Maker, it is reproduceable: returning an expanded header in the _in
function is not appreciated in a very narrow number of cases.
Edit arrayfuncs.c:array_in(), change the return line thus:
// PG_RETURN_ARRAYTYPE_P(retval);
PG_RETURN_DATUM(expand_array(PointerGetDatum(re
re the next step here. Do I click "Move to next CF" in the
"Status" dropdown? Apologies for not being familiar with the protocol.
I'd be sad to see this work just get ignored.
Thanks,
Paul
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To ma
ld
be implemented more accurately.
The code for pg_usleep() could be similar like this:
while(nanosleep(&req,&req)==-1 && errno == EINTR)
continue;
or combine with clock_gettime() to control the sleep time more accurately.
Regards,
Paul
I'm working on a custom aggregate, that generates a serialized data format.
The preparation of the geometry before being formatted is pretty intense,
so it is probably a good thing for that work to be done in parallel, in
partial aggregates. Here's an example SQL call:
EXPLAIN analyze
SELECT lengt
Just clarifying myself a little, since I made a dumb error partway through.
On Thu, Nov 2, 2017 at 10:09 AM, Paul Ramsey
wrote:
> I'm working on a custom aggregate, that generates a serialized data
> format. The preparation of the geometry before being formatted is pretty
> int
On Sat, Nov 4, 2017 at 10:02 PM, Amit Kapila
wrote:
> On Sat, Nov 4, 2017 at 4:43 AM, Tom Lane wrote:
> > Paul Ramsey writes:
> >>> Whether I get a parallel aggregate seems entirely determined by the
> number
> >>> of rows, not the cost of preparing those ro
Lane wrote:
> > Paul Ramsey writes:
> >>> Whether I get a parallel aggregate seems entirely determined by the
> number
> >>> of rows, not the cost of preparing those rows.
> >
> >> This is true, as far as I can tell and unfortunate. Feeding tables wit
All,
As we try and make PostGIS more "parallel sensitive" we have been added
costs to our functions, so that their relative CPU cost is more accurately
reflected in parallel plans.
This has resulted in an odd side effect: some of our "wrapper" functions
stop giving index scans in plans [1]. This
le
> platform for Postgres :-(. I'm sad to hear it, but certainly have
> not got the cycles personally to prevent it.
NetBSD and OpenBSD are different systems. I don’t remember if NetBSD supports
shared libraries on VAX, but that’s independent of the fact that OpenBSD
doesn’t.
correct, so returning NEW or OLD above seems confusing, and
likely a copy/paste error.
This patch just removes those three lines from the example code.
Thanks!
Paul
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index a6088e9..dc29e7c 100644
--- a/doc/src/sgml/plpgsql.sgml
++
The behaviour of generate_series seems to have changed a little, at least
in conjunction w/ CTEs. Under 9.6 (and prior) this query returns 2127 rows,
with no nulls:
with
ij as ( select i, j from generate_series(1, 10) i, generate_series(1, 10)
j),
iijj as (select generate_series(1, i) as a, genera
Thanks Tom. This showed up in a regression test of ours that built the test
data using generate_series, so it's not a critical production issue or
anything, just a surprise change in behaviour.
P.
On Wed, May 24, 2017 at 10:28 AM, Tom Lane wrote:
> Paul Ramsey writes:
> > Th
nition (the "cube,-postgis" entry for example). If that's a
deal-breaker, I can add it too, but it felt like something that could
wait for a user to positively declare "I must have that feature!"
P.
On Fri, Jul 17, 2015 at 5:58 AM, Paul Ramsey wrote:
>
>
On Tue, Jul 21, 2015 at 7:45 AM, Andres Freund wrote:
>> +
>> + /* We need this relation to scan */
>> + depRel = heap_open(DependRelationId, RowExclusiveLock);
>> +
>> + /* Scan the system dependency table for a all entries this operator */
>> + /* depends on, then iterate throug
On July 21, 2015 at 8:26:31 AM, Andres Freund
(and...@anarazel.de(mailto:and...@anarazel.de)) wrote:
> On 2015-07-21 17:00:51 +0200, Andres Freund wrote:
> > On 2015-07-21 07:55:17 -0700, Paul Ramsey wrote:
> > > On Tue, Jul 21, 2015 at 7:45 AM, Andres Freund wrote:
>
On July 21, 2015 at 11:07:36 AM, Tom Lane (t...@sss.pgh.pa.us) wrote:
I'm inclined to think that it's not really necessary to worry about
invalidating a per-connection cache of "is this function safe to ship"
determinations.
So: yes to a local cache of all forwardable functions/ops, populated in
On July 21, 2015 at 11:22:12 AM, Tom Lane (t...@sss.pgh.pa.us) wrote:
> So: yes to a local cache of all forwardable functions/ops, populated in full
> the first time through (does that speak maybe to using a binary search on a
> sorted list instead of a hash, since I only pay the sort price once
On Tue, Jul 21, 2015 at 11:29 AM, Paul Ramsey wrote:
> On July 21, 2015 at 11:22:12 AM, Tom Lane (t...@sss.pgh.pa.us) wrote:
>
> No, *not* populated first-time-through, because that won't handle any of
> the CREATE, DROP, or UPGRADE cases. It's also doing a lot of work you
On July 22, 2015 at 12:15:14 PM, Andres Freund (and...@anarazel.de) wrote:
It doesn't seem that unlikely that somebody does an ALTER SERVER OPTIONS
SET .. to add an extension to be shippable while connections are already
using the fdw. It'll be confusing if some clients are fast and some
others
On Wed, Jul 22, 2015 at 12:19 PM, Paul Ramsey wrote:
>
> I’ll have a look at doing invalidation for the case of changes to the FDW
> wrappers and servers.
Here's an updated patch that clears the cache on changes to foreign
wrappers and servers.
In testing it I came across an u
On Thu, Jul 23, 2015 at 7:48 AM, Paul Ramsey wrote:
> In testing it I came across an unrelated issue which could make it
> hard for users to manage the options on their wrappers/servers
>
> fdw=# ALTER SERVER foreign_server OPTIONS ( extensions 'postgis' );
> ALTER SE
On Thu, Jul 23, 2015 at 7:48 AM, Paul Ramsey wrote:
> Here's an updated patch that clears the cache on changes to foreign
> wrappers and servers.
Any chance one of you folks could by my official commitfest reviewer?
Appreciate all the feedback so far!
https://commitfest.postgresq
Thanks so much Michael! Let me know when you have further feedback I should
incorporate.
ATB,
P.
--
http://postgis.net
http://cleverelephant.ca
On July 25, 2015 at 4:52:11 AM, Michael Paquier (michael.paqu...@gmail.com)
wrote:
On Sat, Jul 25, 2015 at 2:19 AM, Paul Ramsey wrote:
>
Hi hackers, I've been wrestling with this one for a while and gone
down a couple blind alleys, so time to ask the experts.
PostGIS has a couple things different from the extensions that live in contrib,
- it has some GUCs
- it has a versioned loadable library (postgis-2.1.so, postgis-2.2.so, etc)
On August 20, 2015 at 2:17:31 AM, Simon Riggs
(si...@2ndquadrant.com(mailto:si...@2ndquadrant.com)) wrote:
> On 18 August 2015 at 21:03, Paul Ramsey wrote:
>
> > So I need a way to either (a) notice when I already have a (old) copy
> > of the library loaded and avoid trying t
On August 20, 2015 at 7:21:10 AM, Tom Lane
(t...@sss.pgh.pa.us(mailto:t...@sss.pgh.pa.us)) wrote:
> I'm not sure that the situation you describe can be expected to work
> reliably; the problems are far wider than just GUC variables. If two
> different .so's are exposing broadly the same set of C
ll about, so I
welcome suggestions here.
Thanks again,
Paul
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
p half should be okay, but if you
believe it's not I'll go with the int8_numeric approach (in three chunks
instead of two to work around signed-vs-unsigned).
Thanks,
Paul
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
h
Back from summer and conferencing, and finally responding, sorry for
the delay...
On Thu, Aug 20, 2015 at 6:01 PM, Michael Paquier
wrote:
>
>
> if (needlabel)
> appendStringInfo(buf, "::%s",
> -
> format_type_with_typemod(node->consttype,
> -
> node->consttypmod));
> +
> f
On Sat, Sep 26, 2015 at 5:41 AM, Michael Paquier
wrote:
> On Sat, Sep 26, 2015 at 4:29 AM, Paul Ramsey wrote:
>> On Thu, Aug 20, 2015 at 6:01 PM, Michael Paquier wrote:
>> src/backend/utils/adt/format_type.c
>> +/*
>> + * This version allows a nondefault typemo
On September 30, 2015 at 12:54:44 AM, Michael Paquier
(michael.paqu...@gmail.com) wrote:
>> +extern bool extractExtensionList(char *extensionString,
>> + List **extensionOids);
>> What's the point of the boolean status in this new routine? The return
>> value of extractExtensionList is never
On September 30, 2015 at 7:06:58 AM, Tom Lane (t...@sss.pgh.pa.us) wrote:
Paul Ramsey writes:
> Hm. Wouldn't it be just fine if only the server is able to define a
> list of extensions then? It seems to me that all the use-cases of this
> feature require to have a list of exte
On September 30, 2015 at 3:32:21 PM, Michael Paquier
(michael.paqu...@gmail.com) wrote:
OK. Once you can get a new patch done with a reworked
extractExtensionList, I'll get a new look at it in a timely fashion
and then let's move it to a committer's hands.
Done and thanks!
P
--
http://po
Andres,
Thanks so much for the review!
I put all changes relative to your review here if you want a nice colorized
place to check
https://github.com/pramsey/postgres/commit/ed33e7489601e659f436d6afda3cce28304eba50
On October 3, 2015 at 8:49:04 AM, Andres Freund (and...@anarazel.de) wrote:
> +
On October 4, 2015 at 9:56:10 PM, Michael Paquier
(michael.paqu...@gmail.com(mailto:michael.paqu...@gmail.com)) wrote:
> On Sun, Oct 4, 2015 at 11:40 AM, Paul Ramsey wrote:
> > I put all changes relative to your review here if you want a nice colorized
> > place to chec
On Tue, Oct 6, 2015 at 5:32 AM, Andres Freund wrote:
> The problem is basically that cache invalidations can arrive while
> you're building new cache entries. Everytime you e.g. open a relation
> cache invalidations can arrive. Assume you'd written the code like:
> You're avoiding that by only e
On October 6, 2015 at 6:32:36 AM, Andres Freund
(and...@anarazel.de(mailto:and...@anarazel.de)) wrote:
> On 2015-10-06 06:28:34 -0700, Paul Ramsey wrote:
> > +/*
> > + * is_shippable
> > + * Is this object (proc/op/type) shippable to foreign server?
> > + * Chec
On Tue, Oct 6, 2015 at 6:55 AM, Andres Freund wrote:
> On 2015-10-06 06:42:17 -0700, Paul Ramsey wrote:
>> *sigh*, no you’re not missing anything. In moving to the cache and
>> marking things just as “shippable” I’ve lost the test that ensures
>> they are shippable for thi
On Tue, Oct 6, 2015 at 8:52 AM, Andres Freund wrote:
> I think it'd be good to add a test exercising two servers with different
> extensions marked as shippable.
Done,
P
20151006b_postgres_fdw_extensions.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@post
Thanks everyone for the held and feedback on this patch!
--
Paul Ramsey
http://cleverelephant.ca
http://postgis.net
On November 3, 2015 at 3:47:37 PM, Tom Lane (t...@sss.pgh.pa.us) wrote:
Robert Haas writes:
> On Tue, Nov 3, 2015 at 2:57 PM, Tom Lane wrote:
>> Paul Ramse
The attached patch changes web references to PostGIS to point to the actual
community site (postgis.net) which is active, rather than the historical site
(postgis.org).
P.
--
Paul Ramsey
http://cleverelephant.ca
http://postgis.net
postgis_doc.patch
Description: Binary data
--
Sent via
On Wed, Dec 2, 2015 at 1:55 PM, Robert Haas wrote:
> Oops. The new version I've attached should fix this.
I've been trying to see if parallel join has any effect on PostGIS
spatial join queries, which are commonly CPU bound. (My tests [1] on
simple parallel scan were very positive, though quite
On Thu, Dec 10, 2015 at 10:42 PM, Haribabu Kommi
wrote:
>
> Here I attached a POC patch of parallel aggregate based on combine
> aggregate patch. This patch contains the combine aggregate changes
> also. This patch generates and executes the parallel aggregate plan
> as discussed in earlier thread
On December 21, 2015 at 2:33:56 AM, Haribabu Kommi (kommi.harib...@gmail.com)
wrote:
Yes the query is producing more groups according to the selectivity.
For example - scan selectivity - 40, the number of groups - 400
Following is the query:
SELECT tenpoCord,
SUM(yokinZandaka) AS yokinZa
for picking this up! I'm sorry I was not able to work on it
the last few months. I'm very glad to see someone wrapping it up. I'm
not a reviewer, but personally it looks like a good change to me.
Happy holidays,
Paul
--
Sent via pgsql-hackers mailing list (pgsql-hackers
spatial queries. Basically the workloads on things like big
spatial joins are entirely CPU bound, so they are seeing that adding
15 processors makes things 15x faster. Spatial folks would love love
love to see parallel query execution.
--
Paul Ramsey
http://cleverelephant.ca
http://postgis.net
>
>
>
Hello,
After a discussion on IRC in #postgresql, I had a feature suggestion and it
was suggested I write it up here.
I have a large (200GB, 1.7b rows) table with a number of columns, but the
two of interest here are a hstore column, tags and a postgis geometry
column, geom.
There is a GIN index
sql.org/gitweb/?p=postgresql.git;a=commit;h=c3d09b3bd23f5f65b5eb8124a3c7592dad85a50c
Many thanks to Tom and all the pgsql-hackers for all the work you do!
Paul
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
owing makefile in the Postgres dist:
/lib/pgxs/src/makefiles/pgxs.mk: No such file or
directory
What do I need to do to obtain the required files, and does anybody know why,
given Postgres 9.2 is out some time, and 9.3 is in beta, why no prebuild binary
PLJavas exist for 9.2?
Thanks,
Paul
Thx.
Yes, am aware PLJava is a 3rd party lib, just surprised the same party hasn't
built them given they seem to be built all the way to 9.1.
My question was primarily about obtaining pgsx.mk file which is a part of the
PostgreSQL project.
Paul
From: A
>> (And, if we are going to break everything
> in sight, now would be a good time to think about changing typmod to
> something more flexible than one int32.)
As someone who is jamming geometry type, spatial reference number and
dimensionality into said 32bit typmod, let me say emphatically ..
On Sat, Oct 16, 2010 at 10:17 AM, Peter Eisentraut wrote:
> On lör, 2010-10-16 at 09:23 -0700, Paul Ramsey wrote:
>> >> (And, if we are going to break everything
>> > in sight, now would be a good time to think about changing typmod to
>> > something more f
and make it my first submission to
PgSQL.
P.
--
Paul Ramsey
http://cleverelephant.ca
http://postgis.net
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Nov 19, 2013 at 7:32 PM, Tom Lane wrote:
> Paul Ramsey writes:
>> As we've added different kinds of caching, in our own project, we've banged
>> up against problems of multiple functions trying to stuff information into
>> the same pointer, and ended u
Hi Simon,
We do the dance because it’s how we always have and don’t know any other way,
any better way. :) The usual explanation. Is there any place you can point to
that demonstrates your technique?
Thanks!
P
--
Paul Ramsey
http://cleverelephant.ca/
http://postgis.net/
On Sunday
On Sunday, November 24, 2013 at 4:42 PM, Tom Lane wrote:
> The real question of course is whether transaction-level caching is
> appropriate for what they're storing. If they want only statement-level
> caching then using fn_extra is often the right thing.
I'm not certain it is... we get some grea
On Wed, Jan 11, 2017 at 4:29 PM, Josh Berkus wrote:
>
> For that reason, as of today, I am stepping down from the PostgreSQL
> Core Team.
>
Massive thanks Josh, you've been a great advocate and a wonderful bridge
into the PgSQL community for those of us finding our way towards the warm
centre of
I've been trying to figure out an issue with operators not being pushed
down for user defined types, in this case "hstore". TL;DR:
hstore=# explain (verbose) select * from hs_fdw where h -> 'a' = '1';
QUERY PLAN
On Fri, Nov 25, 2016 at 11:30 AM, Paul Ramsey
wrote:
> I've been trying to figure out an issue with operators not being pushed
> down for user defined types, in this case "hstore". TL;DR:
>
> hstore=# explain (verbose) select * from
On Sun, Nov 27, 2016 at 9:31 AM, Tom Lane wrote:
> Paul Ramsey writes:
> > On Fri, Nov 25, 2016 at 11:30 AM, Paul Ramsey >
> > wrote:
> >> I've been trying to figure out an issue with operators not being pushed
> >> down for user defined types, in th
On Sun, Nov 27, 2016 at 11:50 AM, Tom Lane wrote:
> Paul Ramsey writes:
> > On Sun, Nov 27, 2016 at 9:31 AM, Tom Lane wrote:
> >> Why doesn't hs_fdw.h have a collation?
>
> > I think I'm missing something, I cannot find a file like that anywhere.
>
&g
On Tue, Mar 29, 2016 at 12:51 PM, Paul Ramsey wrote:
> On Tue, Mar 29, 2016 at 12:48 PM, Paul Ramsey
> wrote:
>
>>> On the join case, I wonder if it's possible that _st_intersects is not
>>> marked parallel-safe? If that's not the problem, I don't ha
On Fri, Apr 8, 2016 at 8:23 AM, Robert Haas wrote:
> On Fri, Apr 8, 2016 at 1:22 AM, Amit Kapila wrote:
>> Other than that, patch looks good and I have marked it as Ready For
>> Committer. Hope, we get this for 9.6.
>
> Committed. I think this is likely to make parallel query
> significantly mo
On Fri, Apr 8, 2016 at 9:06 AM, Simon Riggs wrote:
> On 8 April 2016 at 17:00, Paul Ramsey wrote:
>>
>> On Fri, Apr 8, 2016 at 8:23 AM, Robert Haas wrote:
>> > On Fri, Apr 8, 2016 at 1:22 AM, Amit Kapila
>> > wrote:
>> >> Other than that, patch
On Tue, Apr 26, 2016 at 6:40 AM, Tom Lane wrote:
> Craig Ringer writes:
>> On 26 April 2016 at 14:06, 陈天舟 wrote:
>>> (1) Since each protocol buffer column requires a schema. I am not sure
>>> where is the best place to store that schema info. Should it be in a
>>> CONSTRAINT (but I am not able t
On Fri, Apr 22, 2016 at 11:44 AM, Stephen Frost wrote:
> Paul,
>
> * Paul Ramsey (pram...@cleverelephant.ca) wrote:
>> On Mon, Mar 28, 2016 at 9:45 AM, Stephen Frost wrote:
>> > Would you agree that it'd be helpful to have for making the st_union()
>> >
On Wed, Feb 25, 2015 at 6:13 AM, Heikki Linnakangas
wrote:
> In the original post on this, you mentioned that the PostGIS guys planned to
> use this to store polygons, as bounding boxes
> (http://www.postgresql.org/message-id/5447b3ff.2080...@sigaev.ru). Any idea
> how would that work?
Poorly, by
Hi all,
I was reading a post from Sushant Sinha about english parser wich do not
consider dot as a word delimiter. In a following mail it has been proposed
to add a patch.
Is there any news about that ?
I would enjoy this patch, too ;)
Thank's
--
Paul Fariello
Étudiant ingéni
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
With PostgreSQL 9.3.5 on Ubuntu 12.04, I'm getting the error:
ERROR: MultiXactId 1934308693 has not been created yet -- apparent
wraparound
on doing various queries on our database. I don't think it is a
wraparound - I think the tuple has mistakenly decided it has a
MultiXactId related to i
On 26/05/2015 10:23, Tatsuo Ishii wrote:
It was fixed in 9.3.7.
OK.
Do you know what the bug number was or what it was called (I've tried
searching for it before posting, but found nothing which seemed to be
the same problem as ours).
Do you know whether, if we upgrade to 9.3.7/8, it wil
On 26/05/2015 16:01, Alvaro Herrera wrote:
Paul Smith wrote:
With PostgreSQL 9.3.5 on Ubuntu 12.04, I'm getting the error:
ERROR: MultiXactId 1934308693 has not been created yet -- apparent
wraparound
on doing various queries on our database. I don't think it is a wraparound -
I
On 26/05/2015 19:47, Alvaro Herrera wrote:
Paul Smith wrote:
No, nothing like that. It was just running fine, and then suddenly (at 2am
on 23 May) it started throwing up loads of these errors. The DB server
wasn't even restarted at that point. It was just working fine, then suddenly
w
such) as well.
There is a PostGIS-specific implementation of this concept here:
https://github.com/pramsey/postgres/blob/9.4-postgres-fdw-postgis/contrib/postgres_fdw
If the approach above sounds OK, I'll genericize my PostGIS specific code to
hand arbitrary extensions and submit a p
On Fri, Apr 25, 2014 at 4:54 PM, Peter Geoghegan wrote:
> 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
> It still says I lack the secret sauce...
> ERROR: could not implement recursive UNION
> DETAIL: All column datatypes must be hashable.
UNION will preferentially glom onto the btree equality operator, if memory
serves. If that isn't also the hash equality operator, things won't work
p
On July 8, 2015 at 1:36:49 PM, Tom Lane (t...@sss.pgh.pa.us) wrote:
Paul Ramsey writes:
>> UNION will preferentially glom onto the btree equality operator, if memory
>> serves. If that isn't also the hash equality operator, things won't work
>> pleasantly.
&
uppport
Synthetic pull request for easy browsing/commenting is here:
https://github.com/pramsey/postgres/pull/1
Thanks!
Paul
diff --git a/contrib/postgres_fdw/deparse.c b/contrib/postgres_fdw/deparse.c
index 81cb2b4..bbe3c9d 100644
--- a/contrib/postgres_fdw/deparse.c
+++ b/contrib
Michael, thanks so much for the review!
On July 15, 2015 at 7:35:11 PM, Michael Paquier (michael.paqu...@gmail.com)
wrote:
This patch includes some diff noise, it would be better to remove that.
Done.
- if (!is_builtin(fe->funcid))
+ if (!is_builtin(fe->funcid) &&
(!is_in_extension(fe->funcid
On July 17, 2015 at 12:49:04 AM, Simon Riggs
(si...@2ndquadrant.com(mailto:si...@2ndquadrant.com)) wrote:
> On 17 July 2015 at 01:23, Michael Paquier wrote:
>
> > > Well, as I see it there’s three broad categories of behavior available:
> > >
> > > 1- Forward nothing non-built-in (current beha
On July 17, 2015 at 5:57:42 AM, Simon Riggs
(si...@2ndquadrant.com(mailto:si...@2ndquadrant.com)) wrote:
> Options already exist on CREATE FOREIGN DATA WRAPPER, so it should be easy to
> support that.
>
> I'd rather add it once on the wrapper than be forced to list all the options
> on every
On Wed, Jun 1, 2016 at 7:52 AM, Jim Nasby wrote:
>
> I suspect another wrinkle here is that in the GIS world a single point can
> be represented it multiple reference/coordinate systems, and it would have
> different values in each of them. AIUI the transforms between those systems
> can be rathe
On Wed, Jun 1, 2016 at 8:59 AM, Jim Nasby wrote:
> On 6/1/16 10:03 AM, Paul Ramsey wrote:
>>
>> We don't depend on these, we have our own :/
>> The real answer for a GIS system is to have an explicit tolerance
>> parameter for calculations like distance/touching/c
oo as select 1
as x; $f$; should be enough to break it
[12:31pm] RhodiumToad: there's no trivial fix
On Wed, Jan 4, 2012 at 11:32 AM, Paul Ramsey wrote:
> One extra detail, my PostgreSQL is compiled with --enable-cassert.
> This is required to set off the killer function.
>
>>
Hello,
There is a buffer overflow in sample code's test_parser.c that can yield to a
segmentation fault. The next byte of the buffer is tested against ' ' before
its availability is checked.
You will find attached a simple patch that fixes the bug.
Paul
--
Semiocast
4. I just
filled out the form on the buildfarm page, so I'm awaiting further
instructions
--
Paul Lindner| | | | | | | | | |
[EMAIL PROTECTED]
pgpVCtLZQqW0p.pgp
Description: PGP signature
uous, and the system takes the column "b" that
exists, rather than returning an error on a column that doesn't exist.
If you were explicit in your column name, you would get an error:
=# select a, (select supdate_test.b from supdate_test) from update_test;
ERROR:
For all that Tom reserved 100 numbers for us, we're only using one right
now.
lwgeom_estimate.c:47:#define STATISTIC_KIND_GEOMETRY 100
Paul
Alvaro Herrera wrote:
Ale Raza wrote:
Simon,
I am forwarding this to pgsql-hackers. I can send the requirements once
I get the right co
1 - 100 of 326 matches
Mail list logo
