[postgis-users] install PostgreSQL

[truongxuan quang]

Thank you very much for your help! but I did not know how to process as you mention, could you please explain as step by step.

So today I tried to do 

1.Add/remove PostgreSQL 

2.delete postgres user and pass by NET USER postgres /delete

3. delete folder of postgreSQL

4. Delete in side regiter of winXP in side KEY_LOCAL_MACHINE\SOFTWARE\PostgreSQL\Installations\

But when I install it still got errors as the detail in install-postgresql.log, I added some few line of the last install-postgresql.log file

Starting the database server...

Executing cscript //NoLogo "C:\Program Files\PostgreSQL\8.4\installer\server\startserver.vbs" postgresql-8.4

Script exit code: 0

Script output:

 Starting postgresql-8.4

Service postgresql-8.4 started successfully

startserver.vbs ran to completion

Script stderr:

 

Loading additional SQL modules...

Executing cscript //NoLogo "C:\Program Files\PostgreSQL\8.4\installer\server\loadmodules.vbs" "postgres" "****" "C:\Program Files\PostgreSQL\8.4" "C:\Program Files\PostgreSQL\8.4\data" 5432 "1"

Script exit code: 0

Script output:

 Installing pl/pgsql in the template1 databases...

    Executing 'C:\DOCUME~1\quang\LOCALS~1\Temp\radEC6B1.bat'...

psql: could not connect to server: Connection refused (0x0000274D/10061)

Is the server running on host "???" and accepting

TCP/IP connections on port 5432?

Installing the adminpack module in the postgres database...

    Executing 'C:\DOCUME~1\quang\LOCALS~1\Temp\radEC6B1.bat'...

psql: could not connect to server: Connection refused (0x0000274D/10061)

Is the server running on host "???" and accepting

TCP/IP connections on port 5432?

loadmodules.vbs ran to completion

Script stderr:

 

[15:40:28] Write the data directory to the ini file...

[15:40:28] Write the port number, service ID, locale and superuser to the ini file...

[15:40:28] Write ServiceID(postgresql-8.4) to registry/ini...

[15:40:28] Write Superuser to ini file and windows registry...

[15:40:28] Write Service Account to ini file and windows registry...

[15:40:28] Write the server description to the ini file...

[15:40:28] Write the server branding to the ini file...

[15:40:28] Write the 'whether stack-builder is disabled or not' to the ini file...

[15:40:28] Finished running post-installation/upgrade tasks.

Creating Uninstaller

Creating uninstaller 25%

Creating uninstaller 50%

Creating uninstaller 75%

Creating uninstaller 100%

Installation completed

Log finished 05/17/11 at 15:40:38

And when I started server by using pgAdim the server response as below:

Server doesn't listen 

the server doesn't accept connections: the connection library repots

could not connect to server: Connection refused (0x0000274D/10061)Is the server running on host "127.0.0.1" and accepting TCP/IP connections on port 5432?

Thank again and very sorry for this question 

Many thanks

T.X.Quang.

---

From: "postgis-us...@postgis.refractions.net" <postgis-us...@postgis.refractions.net>
To: postgi...@postgis.refractions.net
Sent: Mon, May 16, 2011 9:00:02 PM
Subject: postgis-users Digest, Vol 109, Issue 15

Send postgis-users mailing list submissions to
    postgi...@postgis.refractions.net

To subscribe or unsubscribe via the World Wide Web, visit
    http://postgis.refractions.net/mailman/listinfo/postgis-users
or, via email, send a message with subject or body 'help' to
    postgis-us...@postgis.refractions.net

You can reach the person managing the list at
    postgis-u...@postgis.refractions.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of postgis-users digest..."


Today's Topics:

  1. Re: Clip a table using a donut geometry (J?lio Almeida)
  2. Help for my error when I install Postgis (truongxuan quang)
  3. Re: Help for my error when I install Postgis (Ren? Riech)


----------------------------------------------------------------------

Message: 1
Date: Mon, 16 May 2011 15:31:23 +0100
From: J?lio Almeida <julio.augu...@gmail.com>
Subject: Re: [postgis-users] Clip a table using a donut geometry
To: Ralf Suhr <Ralf...@itc-halle.de>
Cc: PostGIS Users Discussion <postgi...@postgis.refractions.net>
Message-ID: <BANLkTikGUwnzvU23...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Thanks Ralf for your suggestion.

I solved it by doing it in two steps.
First, I created a temporary table with the donut geometry:

EXECUTE 'create table tempdonut as SELECT
ST_Difference(st_buffer(the_geom,buffer_radius), the_geom) as the_geom
      from designprocess.dp_zn_boundaries
      where type = site_name);

Second, I did de Intersects query:

EXECUTE 'INSERT INTO  tempdonut SELECT
      r.the_geom, r.gid FROM urbanenvironment.ue_ms_crossings_wegdeel_punt
AS r,  tempdonut as m
      WHERE ST_Intersects(r.the_geom, m.the_geom)';

Thanks again,

j?lio almeida
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://postgis.refractions.net/pipermail/postgis-users/attachments/20110516/212d79ac/attachment-0001.html>

------------------------------

Message: 2
Date: Mon, 16 May 2011 10:23:15 -0700 (PDT)
From: truongxuan quang <truongx...@yahoo.com>
Subject: [postgis-users] Help for my error when I install Postgis
To: postgi...@postgis.refractions.net
Message-ID: <11939.1...@web114704.mail.gq1.yahoo.com>
Content-Type: text/plain; charset="us-ascii"

Dear list

I face with some problem in installation PostgreSQL 8.3 on winXP , long time
before I use PostgreSQL and PostGIS for managing shape file data. Last week I
tried to install PostgreSQL 8.4, after that I remove PostgreSQL 8.3 (I only
uninstalled inside windows control panel/add and then I delete all folder inside
window programs) and I reinstall PostgreSQL 8.4, and problem was starting happen
from this step, until now, I could not connect data by my user and password or
start PostgreSQL8.4 service from Administrative Tools . Even I tried to
uninstall and reinstall for at least 20 times, delete folder, remove
user/password on Administrative Tools.

Could you please help me to fix my problem

Many thanks

T.X.Quang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://postgis.refractions.net/pipermail/postgis-users/attachments/20110516/3cd27eaa/attachment-0001.html>

------------------------------

Message: 3
Date: Mon, 16 May 2011 19:50:34 +0200
From: Ren? Riech <rene....@arcor.de>
Subject: Re: [postgis-users] Help for my error when I install Postgis
To: "PostGIS Users Discussion" <postgi...@postgis.refractions.net>
Message-ID: <op.vvk46kax1ftthu@roarglch>
Content-Type: text/plain; charset=iso-8859-15; format=flowed;
    delsp=yes

On Mon, 16 May 2011 19:23:15 +0200, truongxuan quang 
<truongx...@yahoo.com> wrote:

> Dear list
>
> I face with some problem in installation PostgreSQL 8.3 on winXP , long 
> time
> before I use PostgreSQL and PostGIS for managing shape file data. Last 
> week I
> tried to install PostgreSQL 8.4, after that I remove PostgreSQL 8.3 (I 
> only
> uninstalled inside windows control panel/add and then I delete all 
> folder inside
> window programs) and I reinstall PostgreSQL 8.4, and problem was 
> starting happen
> from this step, until now, I could not connect data by my user and 
> password or
> start PostgreSQL8.4 service from Administrative Tools . Even I tried to
> uninstall and reinstall for at least 20 times, delete folder, remove
> user/password on Administrative Tools.

Hi Truongxuan,


I once had also a problem with a deinstallation of PostgreSQL. I found that
script, It deletes everytthing what stays after the deinstallation.


echo on
@REM 
********************************************************************************
@REM
@REM  NAME          : Remove_PostgreSQL_Total.CMD
@REM
@REM  DESCRIPTION  : Entfernt vollst?ndig alle Verzeichnisse und Eintr?ge 
die durch
@REM                  die De-Installation von PostgreSQL nicht entfernt 
wurden.
@REM
@REM                  Diese Datei darf erst nach der De-Installtion von 
PostgreSQL
@REM                  gestartet werden. Sie mu? von dem User ausgef?hrt 
werden, unter
@REM                  dem die Installation von PostgreSQL erfolgte. 
Normalerweise ist
@REM                  das der Administrator unter Windows.
@REM
@REM                  Die Verzeichnisse beziehen sich auf eine 
PostgreSQL-Standard-
@REM                  Installation!
@REM
@REM 
********************************************************************************

@REM    -------------------------------------------------------------
@REM    Benutzerkonto, unter dem der PostgreSQL-Datenbankserver l?uft
@REM    -------------------------------------------------------------

        @set WIN_USER=postgres

@REM 
================================================================================

        NET USER %WIN_USER% /DELETE

        rmdir /S /Q "%SystemDrive%\Dokumente und 
Einstellungen\%USERNAME%\Anwendungsdaten\PostgreSQL"
        rmdir /S /Q "%SystemDrive%\Dokumente und Einstellungen\%WIN_USER%"
        rmdir /S /Q "%ProgramFiles%\PostgreSQL"



Use this script AFTER the deinstallation of PostgreSQL as an administrator 
user.

maybe this helps.

with regards

Ren?


------------------------------

_______________________________________________
postgis-users mailing list
postgi...@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users


End of postgis-users Digest, Vol 109, Issue 15
**********************************************

[Sylvain Racine]

On 17/05/2011 10:10, truongxuan quang wrote:

Thank you very much for your help! but I did not know how to process as you mention, could you please explain as step by step.

So today I tried to do 

1.Add/remove PostgreSQL 

2.delete postgres user and pass by NET USER postgres /delete

3. delete folder of postgreSQL

4. Delete in side regiter of winXP in side KEY_LOCAL_MACHINE\SOFTWARE\PostgreSQL\Installations\

Hi Truongxuan,

You have the right steps to uninstall PostgreSQL. I don't
think that is your problem. I suspect a password or a
connection problem with your database.

I suppose your try to install PostgreSQL with
installer of EntrepriseDB. If not, please indicate it! We need sufficient
information to reproduce error or bug!

I succeeded this afternoon to reproduce your problem with
this distribution. I installed EntrepriseDB with PostGIS
on a local Win XP Pro machine 32 bits. I got problems when
I typed a password containing "special" characters, like
"été" (I speak French). The installer couldn't connect to
database at the end of the process. I tried to reinstall
and then I used an "English" style password. This time,
the installation has succeeded even if I used a
password different of the one I  used the first time. Notice:
you must manually delete the Windows "postgres" account
before reinstalling. The installation message displays it.

I remarked something  when I install EntrepriseDB. The first
installer (PostgreSQL) is done by BitRock and the second
(PostGIS) is done by Nullsoft. Both ask the superuser
password. I suspect that there is a different charset for 
each installer.

I note also something strange in your log. The name of
your network address is showed as "???" in your log. Did
you replace it yourself or is it exactly what you see in
your log? It looks like if you give a network name with some
"special" characters. Remember to always use English style
words for a computer connection. Anyway, your network address
should be "localhost".

If you have still error messages after these tips, please
post another message with your detailed configuration and
what you did.

Best regard

Sylvain Racine

[G. van Es]

Hi All, 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. 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. Before inventing the wheel again, does anyone know if this procedure already exist or knows perhaps another/better way to achieve this? Thanks in advance, Ge

[Edward Mac Gillavry]

Hi Ge,

You may want to check Probe_Geometry_Columns (http://postgis.refractions.net/docs/Probe_Geometry_Columns.html).

Kind regards,

Edward

---

Date: Wed, 18 May 2011 04:38:51 -0700
From: gves...@yahoo.com
To: postgi...@postgis.refractions.net
Subject: [postgis-users] how to keep geometry_columns in sync with tables and views

[G. van Es]

Hi Edward, This will not work because this function doesn't do anything with views. Also stale records aren't removed. Ge --- On Wed, 5/18/11, Edward Mac Gillavry <emacgi...@hotmail.com> wrote:

-----Inline Attachment Follows-----

[Ben Madin]

Ge,

Try 

    SELECT Populate_Geometry_Columns();

http://postgis.refractions.net/docs/Populate_Geometry_Columns.html

which promises to truncate the geometry columns table first, then rebuild it.

cheers

Ben

[pcr...@pcreso.com]

I foubd this an unfortunately ambiguous name. it doesn't populate geometry columns so much as update the geometry_columns table. But irrespective of the name, it is nice to have :-) Cheers   Brent Wood --- On Thu, 5/19/11, Ben Madin <li...@remoteinformation.com.au> wrote:

[Ben Madin]

G'day Brent,

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?

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?

cheers

Ben

[Paragon Corporation]

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. 

 

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

 

There are a couple of issues with this:

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.

(I say no).

 

2) Exotic uses of geometry_columns that inspecting the system catalogs will not handle (e.g. views and other reasons for manual registration)

 

Anyrate the thread is outlined here:

 

http://trac.osgeo.org/postgis/ticket/944

 

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.

 

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).

 

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.

 

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.

 

Thanks,

Regina

http://www.postgis.us

 

---

From: postgis-us...@postgis.refractions.net [mailto:postgis-us...@postgis.refractions.net] On Behalf Of Ben Madin
Sent: Wednesday, May 18, 2011 9:27 PM
To: pcr...@pcreso.com; PostGIS Users Discussion

[Ben Madin]

Thanks for the heads-up Regina,

I'm not really over most of the issues with type etc, but from my perspective :

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!

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.

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!

cheers

Ben

[Paragon Corporation]

One other note -- the SQL/MM standard calls for an st_geometry_columns view which is a true view that reads the system catalogs and should only read the system catalogs I think.

 

geometry_columns is a left over from OGC standard.  So my other point is if we are going to do things the new way, why don't we call it the new name "st_geometry_columns"

 

So that is why I was proposing a hybrid -- geometry_columns  -- so new PostGIS can work with older tools

 

and st_geometry_columns -- which will be strictly pure new way.

 

Though I suppose that may be more confusing than it's worth and there is the case of views

 

such as the form

 

SELECT .. ST_Transform(..,) As geom

:

 

Which for performance reasons should not be inspected and can not be appropriately represented in system catalogs using typmod approach.

 

Thanks,

Regina

---

From: postgis-us...@postgis.refractions.net [mailto:postgis-us...@postgis.refractions.net] On Behalf Of Ben Madin

Sent: Friday, May 20, 2011 1:40 AM
To: PostGIS Users Discussion
Cc: 'PostGIS Development Discussion'
Subject: Re: [postgis-users] how to keep geometry_columns in sync wit tablesand views (and new PostGIS 2.0 plans)

[Paragon Corporation]

Slight correction in thinking about this more, I suppose if people built their views something like:

 

SELECT ST_Transform(geom,4326)::geometry(POINT,4326) As geom

FROM ...

 

 I guess even complex geometry views can be represented correctly in the system catalogs.

 

I still would want to go with the new name though and treat geometry_columns as a deprecated thing of the past, but I am in a minority here on opinion.

 

Thanks,

Regina

---

From: Paragon Corporation [mailto:l...@pcorp.us]
Sent: Friday, May 20, 2011 3:15 AM

To: 'PostGIS Users Discussion'
Cc: 'PostGIS Development Discussion'

Subject: RE: [postgis-users] how to keep geometry_columns in sync wit tablesand views (and new PostGIS 2.0 plans)

One other note -- the SQL/MM standard calls for an st_geometry_columns view which is a true view that reads the system catalogs and should only read the system catalogs I think.

 

geometry_columns is a left over from OGC standard.  So my other point is if we are going to do things the new way, why don't we call it the new name "st_geometry_columns"

 

So that is why I was proposing a hybrid -- geometry_columns  -- so new PostGIS can work with older tools

 

and st_geometry_columns -- which will be strictly pure new way.

 

Though I suppose that may be more confusing than it's worth and there is the case of views

 

such as the form

 

SELECT .. ST_Transform(..,) As geom

:

 

Which for performance reasons should not be inspected and can not be appropriately represented in system catalogs using typmod approach.

 

Thanks,

Regina

From: postgis-us...@postgis.refractions.net [mailto:postgis-us...@postgis.refractions.net] On Behalf Of Ben Madin

Sent: Friday, May 20, 2011 1:40 AM
To: PostGIS Users Discussion
Cc: 'PostGIS Development Discussion'
Subject: Re: [postgis-users] how to keep geometry_columns in sync wit tablesand views (and new PostGIS 2.0 plans)

[Sandro Santilli]

On Fri, May 20, 2011 at 03:15:26AM -0400, Paragon Corporation wrote:
> One other note -- the SQL/MM standard calls for an st_geometry_columns view
> which is a true view that reads the system catalogs and should only read the
> system catalogs I think.
>
> geometry_columns is a left over from OGC standard. So my other point is if
> we are going to do things the new way, why don't we call it the new name
> "st_geometry_columns"
>
> So that is why I was proposing a hybrid -- geometry_columns -- so new
> PostGIS can work with older tools
>
> and st_geometry_columns -- which will be strictly pure new way.
>
> Though I suppose that may be more confusing than it's worth and there is the
> case of views

Yeah, think about all clients, it would be an hell of configuration to
tell qgis wheter or not to look in st_geometry_columns and/or geometry_columns
and in which order etc. etc.

My opinion is starting to form on this and currently is closer to
"maintain a real table".

typmod might make _populating_ the table easier, and you could still
add entries manually in case there's no way to tell automatically
(due to loose typemod, for example). Also, a real table might let
you add fields for XML metadata to associate to "layers", which we
might account for in 2.0.

Now, we could keep/alter geometry_columns (to add maybe also an identifier
for each layer rather than using a 3/4 columns unique key...) and have
a lame ST_geometry_columns view as naked as ISO likes it, but still querying
the real geometry_columns table.

This is basically suggesting we do _not_ make a view to tell which spatial
layers exist, but we can provide a function to do that, which may be used
but the geometry_column population function...

--strk;

() Free GIS & Flash consultant/developer
/\ http://strk.keybit.net/services.html

[Stephen Frost]

All,

* Sandro Santilli (st...@keybit.net) wrote:
> On Fri, May 20, 2011 at 03:15:26AM -0400, Paragon Corporation wrote:
> > So that is why I was proposing a hybrid -- geometry_columns -- so new
> > PostGIS can work with older tools

Having a hybrid may work for backwards-compatibility reasons, but we
should have a solution which doesn't require such an ugly hack for new
code/systems/etc.

> > Though I suppose that may be more confusing than it's worth and there is the
> > case of views

Regarding views, what I would actually suggest is that we allow users a
way to tell update the typmod for the view definition directly in the
catalog rather than suggesting that they use a seperate table as an
override.

We could do this pretty easily using a function which the user would
call (instead of adding to or updating a table) which would update the
catalog definition for the view. We could also try to see if there's a
way to support doing this through 'alter view'.

> My opinion is starting to form on this and currently is closer to
> "maintain a real table".

This might be acceptable as a backwards-compatibility mode, but I think
we need a solution which doesn't depend on overriding values that are in
the catalog.

Thanks,

Stephen

[Paul Ramsey]

In my mind, the *only* reason I'm spending the time to implement
typmod is to turn geometry_columns into a view. If I'm not getting
that, it's not worth spending the time. The whole point, for me, is
that I can CREATE TABLE and boom my data shows up. There should not be
any required manual steps in general operation. I can just *barely*
get behind having a manually managed side table that gets unioned with
geometry_columns for lunatics who want to hand-enter their own stuff,
but in ordinary operations geometry_columns should just be magically
up-to-date at all times.

P.

[Paragon Corporation]

ST_geometry_columns - for those who wish for purity -- anyone :)

Paul,
Are you suggesting I'm a lunatic? I'm going to check the mirror now to see
if I'm growing fangs :).

I agree with you though -- that is the main beauty of typmod which is why
strk's solution won't work.

I would almost go with forcing everyone to change their existing tables to
typmod if they want to reap the benefits of PostGIS 2.0,
but most of my clients will not go to 2.0 then.

We could try Mark's idea of hacking the catalog tables to automagically
convert table constraints to typmod but that all sounds pretty scary to me.
Especially with my special
Inheritcance case -- I can just see that failing miserably and screwing up
my tables.

Anyrate we can't try any of these until you put in place the typmod feature.

Once you put in place typmod -- I think we can exercise all the various
options to see which evil is the least of all evils.

Thanks,
Regina

-----Original Message-----
From: postgis-us...@postgis.refractions.net
[mailto:postgis-us...@postgis.refractions.net] On Behalf Of Paul
Ramsey
Sent: Friday, May 20, 2011 7:53 AM
To: PostGIS Users Discussion; PostGIS Development Discussion
Subject: Re: [postgis-users] [postgis-devel] how to keep geometry_columns in
sync wit tablesand views (and new PostGIS 2.0 plans)

[Stephen Frost]

* Paragon Corporation (l...@pcorp.us) wrote:
> I would almost go with forcing everyone to change their existing tables to
> typmod if they want to reap the benefits of PostGIS 2.0,
> but most of my clients will not go to 2.0 then.

What I havn't heard yet is any explanation or description of *why* they
wouldn't want to move to 2.0 if it only supported the typmod approach..?

> We could try Mark's idea of hacking the catalog tables to automagically
> convert table constraints to typmod but that all sounds pretty scary to me.

The upgrade question should not be terribly difficult to solve by just
using the current geometry_columns table to help with the generation of
the new tables...?

> Especially with my special
> Inheritcance case -- I can just see that failing miserably and screwing up
> my tables.

Can you provide more insight on this..? I'm not familiar with your
'special inheritance case'..

> Anyrate we can't try any of these until you put in place the typmod feature.
> Once you put in place typmod -- I think we can exercise all the various
> options to see which evil is the least of all evils.

Part of the issue here, however, is if there's something the typmod
approach isn't doing currently that it could/should be doing which would
resolve these concerns...?

Thanks,

Stephen

[Paragon Corporation]

Steve,

* Paragon Corporation (l...@pcorp.us) wrote:
> I would almost go with forcing everyone to change their existing
> tables to typmod if they want to reap the benefits of PostGIS 2.0, but
> most of my clients will not go to 2.0 then.

> What I havn't heard yet is any explanation or description of *why* they
wouldn't want to move to 2.0 if it only supported the typmod approach..?

See my comment in the trac item - (short answer there are some use cases
that just can't be implemented with typmod)
http://trac.osgeo.org/postgis/ticket/944#comment:22

> We could try Mark's idea of hacking the catalog tables to
> automagically convert table constraints to typmod but that all sounds
pretty scary to me.

> The upgrade question should not be terribly difficult to solve by just
using the current geometry_columns table to help with the generation of the
new tables...?

New tables -- oh no, you'd have to do an alter (or as Mark wants directly
update the catalogs) -- imagine the nightmare if you have foreign key
constraints and what not having to create new tables.
I have no tables to test with since we don't have typmod, but once Paul gets
typmod in there (HINT HINT), I can test with fairly large tables to see how
painful doing an alter and dropping constraints would be.

> Especially with my special
> Inheritcance case -- I can just see that failing miserably and
> screwing up my tables.

> Can you provide more insight on this..? I'm not familiar with your
'special inheritance case'..

See trac comment.

Thanks,
Regina
http://www.postgis.us