Sorry for the cross posting on this one, but I think it's important both groups
are aware.
>> I think this thread covers most of the issues.
>> https://lists.osgeo.org/pipermail/postgis-devel/2017-August/026355.html
>> My thought was is it possible for pg_upgrade to be taught to use CREATE
>> EX
stgis-2 from
thenceforward for the life of 2 major series because we don't break backward
compatibility often in a PostGIS minor version got shot down.
Any thoughts on this?
Thanks,
Regina Obe
PostGIS PSC member
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
> But this line of thinking does strengthen my feeling that throwing an
error is the right thing to do for the moment. If we allow v10 to accept
such cases but do something different from what we used to, that
> will greatly complicate any future attempt to try to restore the old
behavior.
>
> After chewing on this for awhile, I'm starting to come to the conclusion
that we'd be best off to throw an error for SRF-inside-CASE (or COALESCE).
Mark is correct that the simplest case of
> SELECT x, CASE WHEN y THEN generate_series(1,z) ELSE 5 END
> FROM table_with_columns_x_and_
> On 6/6/17 13:52, Regina Obe wrote:
>> It seems CREATE AGGREGATE was expanded in 9.6 to support
>> parallelization of aggregate functions using transitions, with the
>> addition of serialfunc and deserialfunc to the aggregate definitions.
>>
>> https://www.
It seems CREATE AGGREGATE was expanded in 9.6 to support parallelization of
aggregate functions using transitions, with the addition of serialfunc and
deserialfunc to the aggregate definitions.
https://www.postgresql.org/docs/10/static/sql-createaggregate.html
I was looking at the PostgreSQL 10
> "Regina Obe" writes:
>> I figured out the culprit was the change in CASE WHEN behavior with
>> set returning functions Had a criteria something of the form:
>> CASE WHEN some_condition_dependent_on_sometable_that_resolves_to_false
>> THEN (regex
> Did something change with how exclusion constraints are handled? I'm
trying to troubleshoot a regression we are having with PostGIS raster
support.
> As best I can guess, it's because exclusion constraints that used to work
in past versions are failing in PostgreSQL 10 with an error something
Did something change with how exclusion constraints are handled? I'm trying
to troubleshoot a regression we are having with PostGIS raster support.
As best I can guess, it's because exclusion constraints that used to work in
past versions are failing in PostgreSQL 10 with an error something like
>> If things are out of order, why isn't just going to was_exact = false
>> good enough?
>>
>> I'm not sure if the mistake is in our PostGIS code or something in
>> PostgreSQL recheck logic.
>> If I change the elog(ERROR ...) to a elog(NOTICE, the answers are
>> correct and sort order is right
I've been trying to troubleshoot the cause of this PostGIS recheck bug we
have reported by two people so far. The last test was a nice simple
repeatable one that triggered the issue:
https://trac.osgeo.org/postgis/ticket/3418
from what I have seen this only affects cases where we are doing a di
The routine in PostGIS to parse out the version number from pg_config is
breaking in the 10 cycle.
Issue seems to be because there is no minor specified.
e.g.
pgconfig --version
returns:
PostgreSQL 10devel
Instead of expected
PostgreSQL 10.0devel
Is this the way it's going to be or will th
> Michael Banck writes:
>> As I've been bitten by this problem recently, I thought I'd take a
>> look at editing the PostGIS extension SQL file to this end, but
>> contrary to the above, the @extschema@ feature only applies to
>> non-relocatable extensions, from src/backend/commands/extension.
> You can change the setting with:
> git config --global core.autocrlf input
> Still, it's fair to wonder if we shouldn't add an entry for this to our
.gitattributes. I'm actually wondering why we wouldn't apply it to ALL text
files in git, not just the extensions Regina mentioned.
> I think the chain of events is that the tiger_data schema is marked as not
to be backed up (because it belongs to an extension) and then all of its
tables are marked as not to be backed up because they're in a schema that's
not to be backed up. The latter
> behavior is meant to implement --exc
I just discovered something which was a little alarming to me.
In the postgis_tiger_geocoder extension, I had switched to having the schema
where user data download is stored created as part of create extension
script so I wouldn't need to check during load.
So I have a statement like this in the
Typo in my last subject line - meant gitattributes. So should have lines
added like below
*.sheol=lf
*.ineol=lf
*.h.in eol=lf
*.h eol=lf
Thanks,
Regina
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subsc
Tom et. al,
Thanks for fixing the SRF function order by thing. That test now passes
now, but there is one other test failing I was going to troubleshoot.
The problem is I can't compile from git postgresql, and the issue is I think
because my git when it pulls down the files they come in as CRLF
> I'm something of a backwards compatibility zealot, but I've become one for
> very good reasons. Personally, I'd rather we'd define precisely the usages
> that are deprecated (I guess SRF-tlist in the presence of
> FROM) and force them to error out with an appropriate HINT rather than give a
In the past couple of weeks our PostGIS tests against PostgreSQL 9.6 dev
started failing. I traced the issue down to a behavior change in 9.6 when
dealing with output of set returning functions when used with (func).*
syntax.
Here is an example not involving PostGIS. Is this an intentional chang
>> On 3/10/16 3:29 PM, Regina Obe wrote:
>> Take for example, I have tiger geocoder which relies on fuzzystrmatch. I
>> have no idea where someone installs fuzzystrmatch so I can't schema qualify
>> those calls. I use that dependent function to use to build an in
> Hmm. The meaning of funcs.inline depends on the search_path, not just during
> dump restoration but all the time. So anything uses it under a different
> search_path setting than the normal one will have this kind of problem; not
> just
> dump/restore.
> I don't have a very good idea wha
-Original Message-
> From: Andreas Karlsson [mailto:andr...@proxel.se]
> Sent: Tuesday, March 08, 2016 10:43 PM
> To: Regina Obe ; 'Robert Haas'
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Is there a way around function search_path killing
>> On Fri, Mar 4, 2016 at 9:29 PM, Regina Obe > wrote:
>> I think the answer to this question is NO, but thought I'd ask.
>>
>> A lot of folks in PostGIS land are suffering from restore issues,
>> materialized view issues etc. because we have functions such a
I think the answer to this question is NO, but thought I'd ask.
A lot of folks in PostGIS land are suffering from restore issues,
materialized view issues etc. because we have functions such as
ST_Intersects
Which does _ST_Intersects AND &&
Since _ST_Intersects is not schema qualified, durin
I'm guessing this is by design but just wanted to confirm that since it
makes this feature not as useful for us.
It also wasn't absolutely clear to me from the documentation.
We are running PostgreSQL 9.5.1 and if we do something like:
CREATE TABLE test(field1 varchar(5) primary key, field2 va
26 matches
Mail list logo