Re: Error: column "nsptablespace" does not exist

From: Andreas Pflug <pgadmin(at)pse-consulting(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>, Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>, Dave Page <dpage(at)vale-housing(dot)co(dot)uk>
Subject: Re: Error: column "nsptablespace" does not exist
Date: 2004-12-05 22:32:34
Message-ID: 41B38C82.3060308@pse-consulting.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Andreas Pflug <pgadmin(at)pse-consulting(dot)de> writes:
>
>>Yes, some kind of information "initdb required because column xxx was
>>dropped" would be helpful. When scanning the whole beta4-to-beta5 file,
>>you'd easily miss the consequence of the 2004-11-05 patch ("remove
>>concept of a schema having an associated tablespace").
>
>
> We do ordinarily say "initdb required" in the changelog message when it
> applies. I unaccountably failed to say that in this particular
> commit message. Entirely my fault, and I do apologize again.

No need for apologies, we're not seeking for the one to blame.

What I'd like to emphasize is that some kind of announcement mechanism
for those of us who code system schema and version dependent stuff is
desirable, exceeding commit messages. psql issues are discussed
integratedly on pgsql-hackers; usually, schema changes are tracked
immediately within the very same cvs commit, making psql a privileged
tool (to me, it's just another tool). Additional tools require the same
attention by maintainers, but it's much harder for them.

Multiversion tools are even more challenging, maintainance not made
easier by the documentation that won't mark version differences
(something like "this feature was added in ..." would be really nice).

If we had some "admin-announcement(at)pgsql(dot)org" list anybody who noticed
some schema relevant change could post there (e.g. usually Dave, Chris
or me will notice sooner or later) instead of just fixing the stuff
silently for his own tool only. Postings by committers who think "hey,
some tool maintainers might want to know this" welcome too.

Regards,
Andreas

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2004-12-05 22:42:10 Re: 8.0.0beta5 FailedAssertion (Crash) when casting composite types
Previous Message elein 2004-12-05 22:27:14 rules, triggers and views