Error: column "nsptablespace" does not exist

Roland Volkmann <roland.volkmann@gmx.de> writes:

with the new Beta5 you will receive an error ""column "nsptablespace"
does not exist"" on phpPgAdmin and EMS PostgreSQL-Manager.

Yup. They need to be fixed.

regards, tom lane

with the new Beta5 you will receive an error ""column "nsptablespace"
does not exist"" on phpPgAdmin and EMS PostgreSQL-Manager. Perhaps there
will be some more applications around which are broken now.

What is the future in this area? Back to schema of Beta4, or must all
the utilities be ported to the new behavour?

You are using a pre-release version of a database server, and
phpPgAdmin's behaviour has had to change _several_ times to track it.

Don't expect a pre-release to work in any way.

We'll fix up phpPgAdmin CVS sometime this week. We might even do a
point release.

No other applications will be broken because no other application is
crazy enough to worry about displaying the tablespace on a schema just yet.

Chris

-----Original Message-----
From: pgsql-hackers-owner@postgresql.org on behalf of Christopher Kings-Lynne
Sent: Sun 11/28/2004 2:57 PM
To: Roland Volkmann
Cc: PostgreSQL Developers
Subject: Re: [HACKERS] Error: column "nsptablespace" does not exist

No other applications will be broken because no other application is
crazy enough to worry about displaying the tablespace on a schema just yet.

Sorry Chris - obviously the pgAdmin team are just a bit crazier than your lot :-)

/D

Hello Christopher, Hello Tom,

thank you for your answers.

You are using a pre-release version of a database server, and
phpPgAdmin's behaviour has had to change _several_ times to track it.

Don't expect a pre-release to work in any way.

I know that PostgreSQL 8.0 isn't ready for use in production
environment. But it's the first native win32 version, so I don't have
any option for my current project, except using another database ;-)
When my project will be ready, I'm sure PostgreSQL will be stable enough.

We'll fix up phpPgAdmin CVS sometime this week. We might even do a
point release.

that's good news - thank you.

With best regards,

Roland

Dave Page wrote:

-----Original Message-----
From: pgsql-hackers-owner@postgresql.org on behalf of Christopher Kings-Lynne
Sent: Sun 11/28/2004 2:57 PM
To: Roland Volkmann
Cc: PostgreSQL Developers
Subject: Re: [HACKERS] Error: column "nsptablespace" does not exist

No other applications will be broken because no other application is
crazy enough to worry about displaying the tablespace on a schema just yet.

Sorry Chris - obviously the pgAdmin team are just a bit crazier than your lot :-)

And a little faster fixing it :-)

Regards,
Andreas

Sorry Chris - obviously the pgAdmin team are just a bit crazier than
your lot :-)

And a little faster fixing it :-)

I didn't even see it go through. Which is weird because I normally
notice that kind of thing...

Chris

Christopher Kings-Lynne wrote:

Sorry Chris - obviously the pgAdmin team are just a bit crazier than
your lot :-)

And a little faster fixing it :-)

I didn't even see it go through. Which is weird because I normally
notice that kind of thing...

Same with us. It's probably the result of the 100+msg thread about
restoring issues with tablespaces. I didn't follow it completely, so I
missed the msg #101 which probably noticed this minor change...

It would have been A Good Thing (tm) if this change had been announced
more clearly, considering the fact that admin tools developers wouldn't
expect such a late change.

Regards,
Andreas

On Monday 29 November 2004 11:03, Andreas Pflug wrote:

Christopher Kings-Lynne wrote:

Sorry Chris - obviously the pgAdmin team are just a bit crazier than
your lot :-)

And a little faster fixing it :-)

I didn't even see it go through. Which is weird because I normally
notice that kind of thing...

Same with us. It's probably the result of the 100+msg thread about
restoring issues with tablespaces. I didn't follow it completely, so I
missed the msg #101 which probably noticed this minor change...

It would have been A Good Thing (tm) if this change had been announced
more clearly, considering the fact that admin tools developers wouldn't
expect such a late change.

Yeah it's the double edged sword that postgresql is maturing to the point that
there are now several admin tools that are 8.0 ready before 8.0 release will
be made, which is normally a good thing. One thing I was thinking about is
don't we normally announce if initdb is required on new beta releases? We
should.

--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

Robert Treat <xzilla@users.sourceforge.net> writes:

don't we normally announce if initdb is required on new beta releases? We
should.

It was sloppy that we didn't do that for beta5, and I apologize for it.

One problem is that we don't have a defined place for per-beta-version
release notes. The current structure of release.sgml doesn't cater for
it --- and I doubt we want to permanently memorialize beta-version
issues anyway. Any thoughts?

regards, tom lane

On Monday 29 November 2004 23:52, Tom Lane wrote:

Robert Treat <xzilla@users.sourceforge.net> writes:

don't we normally announce if initdb is required on new beta releases? We
should.

It was sloppy that we didn't do that for beta5, and I apologize for it.

One problem is that we don't have a defined place for per-beta-version
release notes. The current structure of release.sgml doesn't cater for
it --- and I doubt we want to permanently memorialize beta-version
issues anyway. Any thoughts?

Do the beta changelogs ever end up any place permanent?
(ftp://ftp.postgresql.org/pub/source/v8.0.0beta/ChangeLog-Beta4-to-Beta5)
We could put a more prominant "**INITDB REQUIRED**" announcement in those when
it is required.

--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

Robert Treat wrote:

On Monday 29 November 2004 23:52, Tom Lane wrote:

Robert Treat <xzilla@users.sourceforge.net> writes:

don't we normally announce if initdb is required on new beta releases? We
should.

It was sloppy that we didn't do that for beta5, and I apologize for it.

One problem is that we don't have a defined place for per-beta-version
release notes. The current structure of release.sgml doesn't cater for
it --- and I doubt we want to permanently memorialize beta-version
issues anyway. Any thoughts?

Do the beta changelogs ever end up any place permanent?
(ftp://ftp.postgresql.org/pub/source/v8.0.0beta/ChangeLog-Beta4-to-Beta5)
We could put a more prominant "**INITDB REQUIRED**" announcement in those when
it is required.

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

Regards,
Andreas

Andreas Pflug <pgadmin@pse-consulting.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.

regards, tom lane

Tom Lane wrote:

Andreas Pflug <pgadmin@pse-consulting.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@pgsql.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