longer EPSG WKT2

[Regina Obe]

> EPSG now has an ensemble for ETRS89 and those have many members, e.g.
> 
>   https://epsg.org/crs/wkt/id/25830
> 
> which are well beyond the 2048 size in the table definition.
> 
> I therefore wonder:
> 
>   What version of the EPSG database does postgis come with (seems hard
>   to find in NEWS?)?
> 
>   What is the relationship between the postgis EPSG version and the proj
>   EPSG version?
> 
>   Should the table fields become larger?  Perhaps 16384?
> 
> and
> 
>   If postgis depends on proj, why isn't it just using the EPSG database
>   from proj?
> 
> 
> (This issue was raised by Javier on the proj list.)

It is mostly just using the proj.db.  Anything beyond storage of srid and
auth_srid is considered legacy use in PostGIS.
PostGIS always checks proj.db for core definitions if the auth_srid exists
in the proj.db. The srtext / proj4text is only used of the definitions don't
exist in proj.db.

We've had this debate for a while if PostGIS should just come with an
essentially empty spatial_ref_sys and as part of user responsibility load
what they need to load
from proj.db and even making spatial_ref_sys a view that just wraps a
function that reads from proj.db. That would largely solve the issue with
have with pg_upgrade that in some cases tables are loaded before
spatial_ref_sys is populated.

There was discussion that editing the proj.db is harder to edit than the
spatial_ref_sys for users wanting to define their own custom projection, so
that was the big boo against getting rid of spatial_ref_sys as a table.
Other reason is it would probably kill performance.