<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Aptos;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:12.0pt;
font-family:"Aptos",sans-serif;}
code
{mso-style-priority:99;
font-family:"Courier New";}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Aptos",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link="#467886" vlink="#96607D" style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal>I’m guessing that limit might have come from our source early on. In the early years we only used proj4text field.<o:p></o:p></p><p class=MsoNormal>The general advice is if you want to make changes, you should make it in your proj.db database since that is the first source of truth for PostGIS these days.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>The spatial_ref_sys aside from the srid and auth (maybe, can’t remember) is ignored if the record is in proj.db.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>That said, I see no issue with upping the limit of srtext. The only danger would be if some users have views bound to it. In that case, it will cause an upgrade failure.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Are you running into obstacles with the 2048 size or are you just thinking of aligning it with the CRS WKT standard? This is the first I’m hearing of anyone complaining about the size of the field.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>From:</span></b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> Denis Rykov <rykovd@gmail.com> <br><b>Sent:</b> Wednesday, May 21, 2025 5:08 AM<br><b>To:</b> PostGIS Users Discussion <postgis-users@lists.osgeo.org><br><b>Subject:</b> srtext 2048 length limit<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>I noticed that the <code><span style='font-size:10.0pt'>srtext</span></code> column in the <code><span style='font-size:10.0pt'>spatial_ref_sys</span></code> table has a length limit of 2048 characters. This seems quite restrictive, especially considering the WKT standard does not prescribe a specific maximum length. In fact, it recommends a maximum of 4096 characters for CRS WKT strings. The current limit is therefore only half of what the standard suggests as a recommended maximum.<br><br>Could you please explain the rationale behind this strict limit, and could its extension be considered?<o:p></o:p></p></div></div></div></body></html>