Re: PostGIS dropgeometrycolumn function (Was: Re: [HACKERS] [7.4]

selectivity stats. Paul On Tuesday, February 3, 2004, at 11:00 AM, Tom Lane wrote: Paul Ramsey [EMAIL PROTECTED] writes: In an idea world though, we would construct the thing as a view, so that when you did a CREATE TABLE that included a geometry type, you would automatically get a row

Re: [HACKERS] Multicolumn Indexing using R-Tree

Try using GiST rtree (examples in contrib), GiST supports multi-key indexes. On Tuesday, February 3, 2004, at 06:56 AM, Marcio Caetano wrote: I'm using PostgreSQL 7.3.2 and I need to create a R-Tree index that uses more than one column in a table. When I run the instruction it appears this

[HACKERS] PostGIS Integration

, February 3, 2004, at 12:06 PM, Tom Lane wrote: Paul Ramsey [EMAIL PROTECTED] writes: Oh, now I remember. The deal was not views, it was triggers. Oh, okay. You're right, we don't do triggers on system tables. But couldn't you combine a view on the system tables with storage of additional data outside

Re: [HACKERS] PostgreSQL pre-fork speedup

. -- __ / | Paul Ramsey | Refractions Research \_ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] OO future

in the current TODO. BTW, my examples are only small part of possible OO features, the others ideas are for example define PRIVATE/PUBLIC attributes in composite types and methods, SELECT p.name FROM person p WHERE p.pay-tax() 100; Karel -- __ / | Paul Ramsey

Re: [HACKERS] Trigger on 'create table' ?

We have a similar requirement for PostGIS. In order to meet the OpenGIS specification, we have to maintain a GEOMETRY_COLUMNS table which includes an entry for every column in the db which holds a spatial column. It would be ideal if we could have triggers run on CREATE TABLE, DROP TABLE, and

Re: [HACKERS] Trigger on 'create table' ?

one defined a geometry column, one had to include info about what SRID and what dimension it was, (ala varchar(243)) maybe the whole schmeer could reside in pg_class and geometry_columns would be a trivial view? Crazy? Loony? P. Tom Lane wrote: Paul Ramsey [EMAIL PROTECTED] writes: We have

Re: [HACKERS] 7.4 To Do

We recently finished some evaluations of Oracle, and one of the things which jumped out at me, PostgreSQL booster that I am, was that in 9i Oracle has finally surpassed PostgreSQL in some elements of object-relational technology. Among the things you can do are: - Create new compound object types

Re: [HACKERS] Does anyone know what embedded transactions are?

Reading through their web page, they seem to have decided to try and fund moving their transactional issues into the Java container instead of getting nested transactions into PostgreSQL. It sounds retrograde and risky, but I suppose if they carry it off, they will attain true database

[HACKERS] GiST a second class citizen?

The PostGIS project has been making use of GiST for about a year now and (thanks to the excellent work of Oleg and Teodor) have found it to be a most excellent indexing system. We are about to apply for some government RD funding, and one of our potential subprojects is creating GiST bindings

[HACKERS] 7.3 pg_relcheck oddness

definitions caused \d to start working again on my spatial table. P. -- __ / | Paul Ramsey | Refractions Research | Email: [EMAIL PROTECTED] | Phone: (250) 885-0632 \_ ---(end of broadcast)--- TIP 3: if posting

Re: [HACKERS] 7.3 pg_relcheck oddness

On further investigation, the problem is related to using a 7.2 psql against a 7.3 backend. The \d from the 7.2 psql is not compatible with the 7.3 backend in the case of tables with non-standard types apparently. P. Paul Ramsey wrote: I am poking around at upgrading PostGIS to work

[HACKERS] Maximum Size for Large Object / TOASTed Object

-- __ / | Paul Ramsey | Refractions Research | Email: [EMAIL PROTECTED] | Phone: (250) 885-0632 \_ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

[HACKERS] [Fwd: [postgis-users] Postgis-0.7.4 + PSQL-7.3.1- installation]

Hi guys, There seems to be quite a laundry list of things which have to be patched or otherwise massaged in order to get a cygwin build. Did these get fixed before 7.3.2 rolled out the door? Paul Original Message Subject: [postgis-users] Postgis-0.7.4 + PSQL-7.3.1-

Re: [HACKERS] Numbering of the next release: 8.0 vs 7.4

of view, wouldn't it be better to skip that risky point-O release and go straight to version 8.1? :) -- __ / | Paul Ramsey | Refractions Research | Email: [EMAIL PROTECTED] | Phone: (250) 885-0632 \_ ---(end of broadcast

Re: [HACKERS] A more precise polygon_overlap()

---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html -- __ / | Paul Ramsey | Refractions Research | Email: [EMAIL PROTECTED] | Phone: (250) 885-0632

Re: [HACKERS] Null values in indexes

suspect that they will at least tell you what they had to do to fix it and it could be performed internally. -- __ / | Paul Ramsey | Refractions Research | Email: [EMAIL PROTECTED] | Phone: (250) 885-0632 \_ ---(end of broadcast

[HACKERS] TPC-* Benchmarks

to at least say it has been tested at load level X and works fine. Failing that, all we have is anecdotes and conjecture. :/ -- __ / | Paul Ramsey | Refractions Research | Email: [EMAIL PROTECTED] | Phone: (250) 885-0632 \_ ---(end

[HACKERS] Module Portability

render my database inoperative just by moving my executable installation tree to a new path. Nice. -- __ / | Paul Ramsey | Refractions Research | Email: [EMAIL PROTECTED] | Phone: (250) 885-0632 \_ ---(end of broadcast

Re: [HACKERS] Module Portability

/blah.so or somesuch. Oleg Bartunov wrote: Contrib modules does have such possibility. For example: CREATE FUNCTION ltree_in(opaque) RETURNS opaque AS 'MODULE_PATHNAME' LANGUAGE 'c' with (isstrict); Oleg On Thu, 1 Aug 2002, Paul Ramsey wrote: All this talk of modularity

Re: [HACKERS] Module Portability

Color me embarrased. / Peter Eisentraut wrote: Paul Ramsey writes: It would be nice if pgsql had a 'default library location' Sure. That's why it was implemented in 7.2. -- Peter Eisentraut [EMAIL PROTECTED] -- __ / | Paul Ramsey | Refractions Research

[HACKERS] PostGIS spatial extensions

Tom Lane wrote: [ why is this thread hiding in -patches? It should be on -hackers or -general, methinks. ] Bruce Momjian [EMAIL PROTECTED] writes: Let me suggest a solution. What if we took the part of the GIS code that duplicated our existing code (geometric types) and replaced

Re: [HACKERS] PostGIS spatial extensions

Dave Blasby wrote: The next question is, of course, what does 'semi-compliant' mean? Or, more interesting, why would you want a semi-compliant database? For most people's simple tasks, the built in geometry types are adequate. Those interested in doing more complex tasks will probably

Re: [HACKERS] PostGIS spatial extensions

. The issue of the extensions dependance on the core is pretty important. -- __ / | Paul Ramsey | Refractions Research | Email: [EMAIL PROTECTED] | Phone: (250) 885-0632 \_ ---(end of broadcast)--- TIP 5: Have you

Re: [HACKERS] PostGIS spatial extensions

Peter Eisentraut wrote: The 7.1 RPMs should contain the server side headers somewhere. Earlier versions only included a not very well defined subset of them. Indeed they do (nice!), which brings me to a different question: 1 - I download the tarball 2 - ./configure ; make ; make install

Re: [HACKERS] SELECT * FROM table LIMIT 1; is really slow

the upgrade to GiST? -- __ / | Paul Ramsey | Refractions Research | Email: [EMAIL PROTECTED] | Phone: (250) 885-0632 \_ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] Default Locale in initdb

features of the database which only work correctly with a locale of C will not work by default. This is not new behaviour. (Why are you the only person who posts here who is nameless?) cheers andrew -- __ / | Paul Ramsey | Refractions Research | Email: [EMAIL PROTECTED

[HACKERS] $libdir and 8.0

Short bug report: When installing PgSQL into a non-standard location (like /opt/foo) the configure script decides to install all the contrib libraries and plpglsq into /opt/foo/lib/postgresql. This would be fine, except that backend does not recognize this directory as a place to be searched

Re: [HACKERS] $libdir and 8.0

GUNDUZ wrote: Hi, On Wed, 18 Aug 2004, Paul Ramsey wrote: When installing PgSQL into a non-standard location (like /opt/foo) the configure script decides to install all the contrib libraries and plpglsq into /opt/foo/lib/postgresql. This would be fine, except that backend does not recognize

Re: [HACKERS] $libdir and 8.0

); canonicalize_path(ret_path); } Bruce Momjian wrote: Devrim GUNDUZ wrote: Hi, On Wed, 18 Aug 2004, Paul Ramsey wrote: When installing PgSQL into a non-standard location (like /opt/foo) the configure script decides to install all the contrib libraries and plpglsq into /opt/foo/lib/postgresql. This would be fine

Re: [HACKERS] $libdir and 8.0

? --- Paul Ramsey wrote: Check this out! [EMAIL PROTECTED] bin]$ ./pg_config --pkglibdir /home/pramsey/pgtest/8.0/bin/lib/postgresql ^^^ And yet: ./port/pg_config_paths.h:#define PKGLIBDIR /home/pramsey/pgtest/8.0/lib/postgresql Could

Re: [HACKERS] $libdir and 8.0

then things would have worked. Paul Tom Lane wrote: Paul Ramsey [EMAIL PROTECTED] writes: ... It is the actual binaries that seem to not know where $libdir is supposed to be. Where do they think it is? A useful way to check would be to strace the backend while you're executing createlang

Re: [HACKERS] $libdir and 8.0

plpgsql test [EMAIL PROTECTED] 8.0]$ Magically, everything now works :) Tom Lane wrote: Paul Ramsey [EMAIL PROTECTED] writes: ... It is the actual binaries that seem to not know where $libdir is supposed to be. Where do they think it is? A useful way to check would be to strace the backend while

Re: [HACKERS] $libdir and 8.0

Thanks Tom, Yes, this is beta1, not the CVS tip, so all is golden. Paul Tom Lane wrote: Paul Ramsey [EMAIL PROTECTED] writes: I started the database from /home/pramsey/pgtest/8.0/bin using ./pg_ctl start -D /home/pramsey/pgtest/8.0/data Ah-hah ... and this is 8.0beta1, right, not anything later

Re: [HACKERS] uuid type for postgres

Just an FYI: We also ended up rolling our own uuid type, against libuuid. It seems that uuid is a widespread enough concept that implementors *will* be asked to support it, moderately often. We *could* roll our own (were capable), others are not so lucky, and would have to point out

[HACKERS] Compiling Win32

I have started playing with the pre7.4 code to see if I can compile a win32 version with PostGIS support. So far, finding it a little hard. Is there a wee guide to compiling 7.4 native win32 around? Thanks, Paul -- __ / | Paul Ramsey | Refractions Research | Email

Re: [HACKERS] Compiling Win32

Yep, have done that... Configure even runs right through, but nothing after that. :/ P. Bruce Momjian wrote: No, we are not there yet, but you can download Mingw and Msys to get started. --- Paul Ramsey wrote: I have started

Re: [HACKERS] Feature freeze and the great elog changeover

with the editing; that might be a good thing if they're still willing. There's something upwards of 4000 elog calls to be looked at :-( Do we get error numbers with that? :-) That is the point ... I'd not really be bothering otherwise ... -- __ / | Paul Ramsey

Re: [HACKERS] Feature freeze and the great elog changeover

Tom Lane wrote: Paul Ramsey [EMAIL PROTECTED] writes: Lots of hardcoded english... What makes you think it's hardcoded? We've had internationalization support for awhile. (One of the results I'd like to accomplish in this pass is to reduce the number of junk messages that translators need

Re: [HACKERS] [GENERAL] pg_dump all tables in 7.3.X

Oh, if it's by design then the pg_dump --help text should be updated correspondingly. The online doco is already correct. Tom Lane wrote: Paul Ramsey [EMAIL PROTECTED] writes: We are trying to do an all tables dump using the 7.3.3 pg_dump, but are getting no love. The pg_dump command which

Re: [HACKERS] [GENERAL] pg_dump all tables in 7.3.X

Entirely sure: [EMAIL PROTECTED] pg_dump]$ which pg_dump /opt/pgsql73/bin/pg_dump [EMAIL PROTECTED] pg_dump]$ pg_dump -t * pramsey -- -- PostgreSQL database dump -- [EMAIL PROTECTED] pg_dump]$ Tom Lane wrote: Paul Ramsey [EMAIL PROTECTED] writes: Oh, if it's by design then the pg_dump --help

Re: [HACKERS] CLUSTER in 8.3.5 on GIST indexes loses all rows

FYI, this is not limited to PostGIS GIST, it appears to be all GIST (gid is an integer column and I have loaded btree_gist): pramsey=# create table ttt as select * from counties; SELECT pramsey=# create index gid_bix on ttt using gist (gid); CREATE INDEX pramsey=# select count(*) from ttt; count

Re: [HACKERS] KNNGiST for knn-search (WIP)

I'm sure whatever conclusion -hackers comes to in the end will be the best for pgsql, and I'll be supportive. But until then, let me note from the PostGIS point-of-view: sure would be great to get this in for 8.5 :) P. On Thu, Dec 31, 2009 at 4:26 AM, Greg Stark gsst...@mit.edu wrote: On Wed,

Re: [HACKERS] Where to find kind code for STATISTIC_KIND GEOMETRY?

. This is it, but as Simon stated, you probably want to get the PostGIS guys involved too, so that duplicates can be sorted out. -- Paul Ramsey Refractions Research http://www.refractions.net [EMAIL PROTECTED] Phone: 250-383-3022 Cell: 250-885-0632 ---(end

Re: [HACKERS] Where to find kind code for STATISTIC_KIND GEOMETRY?

. -Original Message- From: Paul Ramsey [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 01, 2007 3:58 PM To: Ale Raza; pgsql-hackers@postgresql.org Cc: John Baleja; PostGIS Development Discussion Subject: Re: [HACKERS] Where to find kind code for STATISTIC_KIND GEOMETRY? For all that Tom

[HACKERS] Access to Row ID information in Functions

In PostGIS, we have a problem, in that spatial operations are very costly, CPUwise. We have hit on a nifty enhancement recently, which was to recognize that when processing multiple rows, in joins or with literal argouments, for most functions of the form GeometryOperation(A, B), A (or B) tended

Re: [HACKERS] Access to Row ID information in Functions

Thanks Tom, Yes, we've discussed adding some kind of optional identity information to the object, it remains a potential course of action. Paul On Tue, Apr 1, 2008 at 2:37 PM, Tom Lane [EMAIL PROTECTED] wrote: Paul Ramsey [EMAIL PROTECTED] writes: The optimized form gets cached

Re: [HACKERS] Modifying and solidifying contrib

definitions along for a ride in the dump process. What we really want is just the data. -- Paul Ramsey Refractions Research http://www.refractions.net [EMAIL PROTECTED] Phone: 250-383-3022 Cell: 250-885-0632 ---(end of broadcast)--- TIP 5

Re: [HACKERS] [BUGS] BUG #6379: SQL Function Causes Back-end Crash

:31pm] RhodiumToad: there's no trivial fix On Wed, Jan 4, 2012 at 11:32 AM, Paul Ramsey pram...@cleverelephant.ca wrote: One extra detail, my PostgreSQL is compiled with --enable-cassert. This is required to set off the killer function. On Wed, Jan 04, 2012 at 07:17:17PM +, pram

Re: [HACKERS] Parallel query execution

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

Re: [HACKERS] knngist - 0.8

(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 ...

Re: [HACKERS] knngist - 0.8

On Sat, Oct 16, 2010 at 10:17 AM, Peter Eisentraut pete...@gmx.net 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 flexible than one int32

[HACKERS] Traffic jams in fn_extra

to handle it and make it a hash* if it's null, whatever API makes sense) so that multiple bits of code can cache state over function calls without banging into one another? flinfo-fn_extra_hash perhaps? If this sounds OK, I'd be honored to try and make it my first submission to PgSQL. P. -- Paul

Re: [HACKERS] Traffic jams in fn_extra

On Tue, Nov 19, 2013 at 7:32 PM, Tom Lane t...@sss.pgh.pa.us wrote: Paul Ramsey pram...@cleverelephant.ca 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

Re: [HACKERS] Traffic jams in fn_extra

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

Re: [HACKERS] Traffic jams in fn_extra

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 great

[HACKERS] Hashable custom types

one be hooked up somewhere else? In an operator? Thanks, 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

Re: [HACKERS] compress method for spgist - 2

On Wed, Feb 25, 2015 at 6:13 AM, Heikki Linnakangas hlinnakan...@vmware.com 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

[HACKERS] Extension support for postgres_fdw

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 patch. Thanks! Paul -- Paul Ramsey http

[HACKERS] GiST KNN Crasher

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

[HACKERS] Extension upgrade and GUCs

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,

Re: [HACKERS] Extension upgrade and GUCs

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 to setup the GUC

Re: [HACKERS] Extension upgrade and GUCs

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

Re: [HACKERS] [PATCH] postgres_fdw extension support

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 pram

Re: [HACKERS] [PATCH] postgres_fdw extension support

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

Re: [HACKERS] [PATCH] postgres_fdw extension support

On Tue, Jul 21, 2015 at 7:45 AM, Andres Freund and...@anarazel.de 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

Re: [HACKERS] [PATCH] postgres_fdw extension support

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

Re: [HACKERS] [PATCH] postgres_fdw extension support

  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: So, right after reading

Re: [HACKERS] [PATCH] postgres_fdw extension support

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

Re: [HACKERS] [PATCH] postgres_fdw extension support

On Tue, Jul 21, 2015 at 11:29 AM, Paul Ramsey pram...@cleverelephant.ca 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

Re: [HACKERS] [PATCH] postgres_fdw extension support

On Thu, Jul 23, 2015 at 7:48 AM, Paul Ramsey pram...@cleverelephant.ca 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

Re: [HACKERS] [PATCH] postgres_fdw extension support

On Wed, Jul 22, 2015 at 12:19 PM, Paul Ramsey pram...@cleverelephant.ca 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

Re: [HACKERS] [PATCH] postgres_fdw extension support

On Thu, Jul 23, 2015 at 7:48 AM, Paul Ramsey pram...@cleverelephant.ca 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 SERVER

Re: [HACKERS] [PATCH] postgres_fdw extension support

  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 behavior)

Re: [HACKERS] [PATCH] postgres_fdw extension support

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

Re: [HACKERS] [PATCH] postgres_fdw extension support

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,

[HACKERS] [PATCH] postgres_fdw extension support

Hi all, Attached is a patch that implements the extension support discussed at PgCon this year during the FDW unconference sesssion. Highlights: * Pass extension operators and functions to the foreign server * Only send ops/funcs if the foreign server is declared to support the relevant

Re: [HACKERS] [PATCH] postgres_fdw extension support

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 pram...@cleverelephant.ca wrote: On July 17, 2015 at 5:57:42 AM, Simon Riggs (si...@2ndquadrant.com

Re: [HACKERS] [PATCH] postgres_fdw extension support

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 <robertmh...@gmail.com> writes: > On Tue, Nov 3, 2015 at 2:57 PM, To

Re: [HACKERS] [PATCH] postgres_fdw extension support

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

Re: [HACKERS] Hashable custom types

On July 8, 2015 at 1:36:49 PM, Tom Lane (t...@sss.pgh.pa.us) wrote: Paul Ramsey pram...@cleverelephant.ca 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.   So… what

Re: [HACKERS] Hashable custom types

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

Re: [HACKERS] Hashable custom types

On Fri, Apr 25, 2014 at 4:54 PM, Peter Geoghegan p...@heroku.com wrote: On Fri, Apr 25, 2014 at 4:47 PM, Paul Ramsey pram...@cleverelephant.ca 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

Re: [HACKERS] [PATCH] postgres_fdw extension support

On September 30, 2015 at 7:06:58 AM, Tom Lane (t...@sss.pgh.pa.us) wrote: Paul Ramsey <pram...@cleverelephant.ca> 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

Re: [HACKERS] [PATCH] postgres_fdw extension support

 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 -- 

Re: [HACKERS] [PATCH] postgres_fdw extension support

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: >

Re: [HACKERS] [PATCH] postgres_fdw extension support

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

Re: [HACKERS] [PATCH] postgres_fdw extension support

On Sat, Sep 26, 2015 at 5:41 AM, Michael Paquier <michael.paqu...@gmail.com> 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 ve

Re: [HACKERS] [PATCH] postgres_fdw extension support

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, > - >

Re: [HACKERS] [PATCH] postgres_fdw extension support

  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

Re: [HACKERS] [PATCH] postgres_fdw extension support

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

Re: [HACKERS] [PATCH] postgres_fdw extension support

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

Re: [HACKERS] [PATCH] postgres_fdw extension support

On Tue, Oct 6, 2015 at 6:55 AM, Andres Freund <and...@anarazel.de> 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

Re: [HACKERS] parallel joins, and better parallel explain

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

Re: [HACKERS] Parallel Aggregate

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

[HACKERS] [PATCH] PostGIS Doc Urls

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

Re: [HACKERS] Parallel Aggregate

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

Re: [HACKERS] Floating point comparison inconsistencies of the geometric types

On Wed, Jun 1, 2016 at 8:59 AM, Jim Nasby <jim.na...@bluetreble.com> 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 ca

Re: [HACKERS] Floating point comparison inconsistencies of the geometric types

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

[HACKERS] Expanded Object Header and Flat Cache

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

  1   2   >