<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Thanks for the heads-up Regina,<div><br></div><div>I'm not really over most of the issues with type etc, but from my perspective :</div><div><br></div><div>I'm not a big fan of doing things because of specifications written in the past - I've never really understood the geometry_columns table as anything except a metadata table - and while I'm sure that there are advantages in terms of clients connection management, as someone who rarely has more than 50 -80 tables (each with only 1 or 2 geometry columns) and only Gigabytes of data, not Terabytes, since the introduction of functions like populate_geometry_columns(), I've not worried too much about it. It was a pain prior to that!</div><div><br></div><div>My concerns (from my use case!) would relate to the risk that clients might struggle to find a table that doesn't exist, or isn't the one that is updated. I suspect that applications under current development would / could be changed, and those that are older may not support the update to 2.0 anyway. Probably better not to go the hybrid route - it might get worse than ugly.</div><div><br></div><div>If you are going to make a change, I agree that a major version is the time to do it. We would probably selectively not migrate certain applications rather than going down the line of upgrading and rewriting code - I don't suppose that is a surprise to many people!</div><div><br></div><div>cheers</div><div><br></div><div>Ben</div><div><br></div><div><br></div><div><br><div><div>On 20/05/2011, at 1:26 AM, Paragon Corporation wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space">
<div dir="ltr" align="left"><span class="400171317-19052011"><font color="#0000ff" size="2" face="Arial">Populate_Geometry_Columns is a function introduced in PostGIS
1.4. So yes you are right the probe_geometry_columns is a lighter weight that
doesn't look at views and just looks at the constraints of
tables. </font></span></div>
<div dir="ltr" align="left"><span class="400171317-19052011"><font color="#0000ff" size="2" face="Arial"></font></span> </div>
<div dir="ltr" align="left"><span class="400171317-19052011"><font color="#0000ff" size="2" face="Arial">Speaking of this. In PostGIS 2.0, the plan is to use
typmod support for geometry (like what we currently have for geography) as
well and make geometry_columns a view instead of a table as it is
now</font></span></div>
<div dir="ltr" align="left"><span class="400171317-19052011"><font color="#0000ff" size="2" face="Arial"></font></span> </div>
<div dir="ltr" align="left"><span class="400171317-19052011"><font color="#0000ff" size="2" face="Arial">There are a couple of issues with this:</font></span></div>
<div dir="ltr" align="left"><span class="400171317-19052011"><font color="#0000ff" size="2" face="Arial">1) Existing data does not use typmod so there is a portability
question of if people want to use the new geometry_columns should they be forced
to convert their data to typmod.</font></span></div>
<div dir="ltr" align="left"><span class="400171317-19052011"><font color="#0000ff" size="2" face="Arial">(I say no).</font></span></div>
<div dir="ltr" align="left"><span class="400171317-19052011"><font color="#0000ff" size="2" face="Arial"></font></span> </div>
<div dir="ltr" align="left"><span class="400171317-19052011"><font color="#0000ff" size="2" face="Arial">2) Exotic uses of geometry_columns that inspecting the system
catalogs will not handle (e.g. views and other reasons for manual
registration)</font></span></div>
<div dir="ltr" align="left"><span class="400171317-19052011"><font color="#0000ff" size="2" face="Arial"></font></span> </div>
<div dir="ltr" align="left"><span class="400171317-19052011"><font color="#0000ff" size="2" face="Arial">Anyrate the thread is outlined here: </font></span></div>
<div dir="ltr" align="left"><span class="400171317-19052011"><font color="#0000ff" size="2" face="Arial"></font></span> </div>
<div><font color="#0000ff" size="2" face="Arial"><a href="http://trac.osgeo.org/postgis/ticket/944">http://trac.osgeo.org/postgis/ticket/944</a></font></div>
<div><font color="#0000ff" size="2" face="Arial"></font> </div>
<div><span class="400171317-19052011"><font color="#0000ff" size="2" face="Arial">I
think the typmod is a done deal -- we are all in agreement we want this.
What is not a done deal is how best to formulate geometry_columns
view.</font></span></div>
<div><span class="400171317-19052011"><font color="#0000ff" size="2" face="Arial"></font></span> </div>
<div><span class="400171317-19052011"><font color="#0000ff" size="2" face="Arial">I
proposed a hybrid -- where part of the geometry_columns view reads from the
system catalog and the other part reads from a static table (basically old
geometry_columns table would be renamed and populate and so forth would be
changed to add to this table).</font></span></div>
<div><span class="400171317-19052011"><font color="#0000ff" size="2" face="Arial"></font></span> </div>
<div><span class="400171317-19052011"><font color="#0000ff" size="2" face="Arial">Anyway
I admit the hybrid is less than pretty, but the alternatives look even more ugly
to me from a migration standpoint and supporting more exotic
uses.</font></span></div>
<div><span class="400171317-19052011"><font color="#0000ff" size="2" face="Arial"></font></span> </div>
<div><span class="400171317-19052011"><font color="#0000ff" size="2" face="Arial">We'd
be interested in hearing how people feel about these approaches and any other
ideas as to how we can fuse the old with the new.</font></span></div>
<div><span class="400171317-19052011"><font color="#0000ff" size="2" face="Arial"></font></span> </div>
<div><span class="400171317-19052011"><font color="#0000ff" size="2" face="Arial">Thanks,</font></span></div>
<div><span class="400171317-19052011"><font color="#0000ff" size="2" face="Arial">Regina</font></span></div>
<div><span class="400171317-19052011"><font color="#0000ff" size="2" face="Arial"><a href="http://www.postgis.us/">http://www.postgis.us</a></font></span></div>
<div><span class="400171317-19052011"><font color="#0000ff" size="2" face="Arial"></font></span> </div>
<div><br></div>
<div dir="ltr" lang="en-us" class="OutlookMessageHeader" align="left">
<hr tabindex="-1">
<font size="2" face="Tahoma"><b>From:</b>
<a href="mailto:postgis-users-bounces@postgis.refractions.net">postgis-users-bounces@postgis.refractions.net</a>
[mailto:postgis-users-bounces@postgis.refractions.net] <b>On Behalf Of </b>Ben
Madin<br><b>Sent:</b> Wednesday, May 18, 2011 9:27 PM<br><b>To:</b>
<a href="mailto:pcreso@pcreso.com">pcreso@pcreso.com</a>; PostGIS Users Discussion<br><b>Subject:</b> Re:
[postgis-users] how to keep geometry_columns in sync with tables and
views<br></font><br></div>
<div></div>
<div>G'day Brent,</div>
<div><br></div>
<div>I'm forever creating tables as subsets of existing tables so it is a truly
useful function, however, I've suffered the same concerns - perhaps it is
worth pursuing the name being changed?</div>
<div><br></div>
<div>I've also never really understood the distinction between the populate_ and
the probe_ functions? the probe_ one appears to be a 'lite' version, but it may
have some other purpose that I don't understand?</div>
<div><br></div>
<div>cheers</div>
<div><br></div>
<div>Ben</div>
<div><br></div>
<div><br>
<div><br></div>
<div><br></div>
<div><br>
<div>
<div>On 19/05/2011, at 9:02 AM, <a href="mailto:pcreso@pcreso.com">pcreso@pcreso.com</a> wrote:</div><br class="Apple-interchange-newline">
<blockquote type="cite">
<table border="0" cellspacing="0" cellpadding="0">
<tbody>
<tr>
<td valign="top">I foubd this an unfortunately ambiguous name.<br><br>it
doesn't populate geometry columns so much as update the geometry_columns
table.<br><br>But irrespective of the name, it is nice to have
:-)<br><br><br>Cheers<br><br> Brent Wood<br><br>--- On <b>Thu,
5/19/11, Ben Madin <i><<a href="mailto:lists@remoteinformation.com.au">lists@remoteinformation.com.au</a>></i></b>
wrote:<br>
<blockquote style="BORDER-LEFT: rgb(16,16,255) 2px solid; PADDING-LEFT: 5px; MARGIN-LEFT: 5px"><br>From:
Ben Madin <<a href="mailto:lists@remoteinformation.com.au">lists@remoteinformation.com.au</a>><br>Subject:
Re: [postgis-users] how to keep geometry_columns in sync with tables
and views<br>To: "PostGIS Users Discussion" <<a href="mailto:postgis-users@postgis.refractions.net">postgis-users@postgis.refractions.net</a>><br>Date:
Thursday, May 19, 2011, 12:50 PM<br><br>
<div id="yiv25696554">Ge,
<div><br></div>
<div>Try </div>
<div><br></div>
<div> SELECT Populate_Geometry_Columns();
<div><br></div>
<div><a href="http://postgis.refractions.net/docs/Populate_Geometry_Columns.html" rel="nofollow" target="_blank">http://postgis.refractions.net/docs/Populate_Geometry_Columns.html</a></div>
<div><br></div>
<div>which promises to truncate the geometry columns table first, then
rebuild it.</div>
<div><br></div>
<div>cheers</div>
<div><br></div>
<div>Ben</div>
<div><br></div>
<div><br></div>
<div><br>
<div>
<div>On 18/05/2011, at 8:05 PM, G. van Es wrote:</div><br class="yiv25696554Apple-interchange-newline">
<blockquote type="cite">
<table border="0" cellspacing="0" cellpadding="0">
<tbody>
<tr>
<td style="FONT-FAMILY: inherit; font-size-adjust: inherit; font-stretch: inherit" valign="top">Hi Edward,<br><br>This will not work because this
function doesn't do anything with views. Also stale records
aren't removed.<br><br>Ge<br><br>--- On <b>Wed, 5/18/11,
Edward Mac Gillavry <i><<a href="x-msg://119/mc/compose?to=emacgillavry@hotmail.com" rel="nofollow" target="_blank" ymailto="mailto:emacgillavry@hotmail.com">emacgillavry@hotmail.com</a>></i></b>
wrote:<br>
<blockquote style="BORDER-LEFT: rgb(16,16,255) 2px solid; PADDING-LEFT: 5px; MARGIN-LEFT: 5px"><br>From:
Edward Mac Gillavry <<a href="x-msg://119/mc/compose?to=emacgillavry@hotmail.com" rel="nofollow" target="_blank" ymailto="mailto:emacgillavry@hotmail.com">emacgillavry@hotmail.com</a>><br>Subject:
Re: [postgis-users] how to keep geometry_columns in sync
with tables and views<br>To: <a href="x-msg://119/mc/compose?to=postgis-users@postgis.refractions.net" rel="nofollow" target="_blank" ymailto="mailto:postgis-users@postgis.refractions.net">postgis-users@postgis.refractions.net</a><br>Date:
Wednesday, May 18, 2011, 4:57 AM<br><br>
<div id="yiv25696554">
<style>#yiv25696554 .yiv25696554hmmessage P {
PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px
}
#yiv25696554 .yiv25696554hmmessage {
FONT-FAMILY: Tahoma; FONT-SIZE: 10pt
}
</style>
Hi Ge,<br><br>You may want to check Probe_Geometry_Columns
(<a href="http://postgis.refractions.net/docs/Probe_Geometry_Columns.html" rel="nofollow" target="_blank">http://postgis.refractions.net/docs/Probe_Geometry_Columns.html</a>).<br><br>Kind
regards,<br><br>Edward<br><br><br><br>
<hr id="yiv25696554stopSpelling">
Date: Wed, 18 May 2011 04:38:51 -0700<br>From: <a href="x-msg://119/mc/compose?to=gves2000@yahoo.com" rel="nofollow" target="_blank" ymailto="mailto:gves2000@yahoo.com">gves2000@yahoo.com</a><br>To:
<a href="x-msg://119/mc/compose?to=postgis-users@postgis.refractions.net" rel="nofollow" target="_blank" ymailto="mailto:postgis-users@postgis.refractions.net">postgis-users@postgis.refractions.net</a><br>Subject:
[postgis-users] how to keep geometry_columns in sync with
tables and views<br><br>
<table border="0" cellspacing="0" cellpadding="0">
<tbody>
<tr>
<td style="FONT-FAMILY: inherit; font-size-adjust: inherit; font-stretch: inherit" valign="top">Hi All,<br><br>We have a lot of tables and
views updated, or better said, replaced on a daily
basis. We have seen that under certain conditions
(which are unclear) entries of the geometry_columns
table are removed. So a mismatch occurs so now and
then resulting in showing either no data or being very
slow when an application has to do a table scan to
obtain the geometry type.<br><br>What I like to have
is a procedure which checks all tables and views
against the geometry_columns table and makes if
necessary the right corrections.<br><br>Before
inventing the wheel again, does anyone know if this
procedure already exist or knows perhaps
another/better way to achieve this? <br><br>Thanks in
advance,<br><br>Ge<br><br><br><br><br></td></tr></tbody></table><br>_______________________________________________
postgis-users mailing list <a href="x-msg://119/mc/compose?to=postgis-users@postgis.refractions.net" rel="nofollow" target="_blank" ymailto="mailto:postgis-users@postgis.refractions.net">postgis-users@postgis.refractions.net</a>
<a href="http://postgis.refractions.net/mailman/listinfo/postgis-users" rel="nofollow" target="_blank">http://postgis.refractions.net/mailman/listinfo/postgis-users</a>
</div><br>-----Inline Attachment Follows-----<br><br>
<div class="yiv25696554plainMail">_______________________________________________<br>postgis-users
mailing list<br><a rel="nofollow">postgis-users@postgis.refractions.net</a><br><a href="http://postgis.refractions.net/mailman/listinfo/postgis-users" rel="nofollow" target="_blank">http://postgis.refractions.net/mailman/listinfo/postgis-users</a><br></div></blockquote></td></tr></tbody></table>_______________________________________________<br>postgis-users
mailing list<br><a href="x-msg://119/mc/compose?to=postgis-users@postgis.refractions.net" rel="nofollow" target="_blank" ymailto="mailto:postgis-users@postgis.refractions.net">postgis-users@postgis.refractions.net</a><br><a href="http://postgis.refractions.net/mailman/listinfo/postgis-users">http://postgis.refractions.net/mailman/listinfo/postgis-users</a><br></blockquote></div><br></div></div></div><br>-----Inline
Attachment Follows-----<br><br>
<div class="plainMail">_______________________________________________<br>postgis-users
mailing list<br><a href="x-msg://119/mc/compose?to=postgis-users@postgis.refractions.net" ymailto="mailto:postgis-users@postgis.refractions.net">postgis-users@postgis.refractions.net</a><br><a href="http://postgis.refractions.net/mailman/listinfo/postgis-users" target="_blank">http://postgis.refractions.net/mailman/listinfo/postgis-users</a><br></div></blockquote></td></tr></tbody></table>_______________________________________________<br>postgis-users
mailing list<br><a href="mailto:postgis-users@postgis.refractions.net">postgis-users@postgis.refractions.net</a><br><a href="http://postgis.refractions.net/mailman/listinfo/postgis-users">http://postgis.refractions.net/mailman/listinfo/postgis-users</a><br></blockquote></div><br></div></div></div>
_______________________________________________<br>postgis-users mailing list<br><a href="mailto:postgis-users@postgis.refractions.net">postgis-users@postgis.refractions.net</a><br>http://postgis.refractions.net/mailman/listinfo/postgis-users<br></blockquote></div><br></div></body></html>