Opened 6 years ago
Closed 5 years ago
#3867 closed defect (fixed)
Can't load against PostgreSQL 11 head DatumGetJsonb renamed
|Reported by:||robe||Owned by:||pramsey|
CREATE FUNCTION psql:/var/lib/jenkins/workspace/postgis/branches/2.5/regress/00-regress-install/share/contrib/postgis/postgis.sql:97: ERROR: could not load library "/var/lib/jenkins/workspace/postgis/branches/2.5/regress/00-regress-install/lib/postgis-2.5.so": /var/lib/jenkins/workspace/postgis/branches/2.5/regress/00-regress-install/lib/postgis-2.5.so: undefined symbol: DatumGetJsonb
Change History (7)
comment:1 by , 6 years ago
comment:2 by , 6 years ago
|Summary:||Can't load against PostgreSQL 11 head → Can't load against PostgreSQL 11 head DatumGetJsonb renamed|
comment:3 by , 6 years ago
comment:4 by , 6 years ago
|Milestone:||PostGIS 2.5.0 → PostGIS 2.4.1|
I'll backport this to PostGIS 2.4.1 after we have released 2.4.0.
comment:5 by , 6 years ago
I haven't backported this yet because strk said he wanted to define it as a macro for pre-11 versions and then call the macro instead of the if-def clauses everywhere we need them.
pramsey you okay with that? For 2.4.1 I want to just go with the IF-Def as done above since we aren't going to be augmenting that and I hate indirection code that is only used in one place.
We don't use ranges yet and I think JSONB is the only one at issue here. For 2.5 main benefit I see to having it as a macro is that if we do use JSONB in other areas of our code (which sounds likely) — e.g. we create a ST_AsGeoJSON that can take an anyelement and return a fully qualified jsonb object, then having this isolated to the macro would be nice.
comment:6 by , 5 years ago
Yes, that approach (macro) is fine. I actually looked to see if pgsql had one already but no.
comment:7 by , 5 years ago
|Status:||new → closed|
I think it was this commit that broke 'r code.
Looks like DatumGetJsonb, should now be called DatumGetJsonbP