Re: pg_tablespace.spclocation column removed in 9.2

Hello, Pgsql-bugs.

According to the "Moving tablespaces" thread started by Bruce
http://archives.postgresql.org/pgsql-docs/2011-12/msg00003.php
pg_tablespace.spclocation column is removed in the 9.2beta. However
this breaks backward compatibility for a bunch of products, e.g.
pgAdmin, phpPgAdmin, PgMDD etc.

I'm not sure this is the best choice. Because each application with
tablespace support will need additional check now to determine what
way to use for obtaining tablespace location:
pg_get_tablespace_location(oid) or tablespace.spclocation

I'm aware of problems caused by this hard coded column. My proposal is
to convert pg_tablespace to system view may be?

--
With best wishes,
Pavel mailto:pavel(at)gf(dot)microolap(dot)com

Hi Pavel,

On Mon, 2012-06-25 at 08:26 +0300, Pavel Golub wrote:
> Hello, Pgsql-bugs.
>
> According to the "Moving tablespaces" thread started by Bruce
> http://archives.postgresql.org/pgsql-docs/2011-12/msg00003.php
> pg_tablespace.spclocation column is removed in the 9.2beta. However
> this breaks backward compatibility for a bunch of products, e.g.
> pgAdmin, phpPgAdmin, PgMDD etc.
>
> I'm not sure this is the best choice. Because each application with
> tablespace support will need additional check now to determine what
> way to use for obtaining tablespace location:
> pg_get_tablespace_location(oid) or tablespace.spclocation
>
> I'm aware of problems caused by this hard coded column. My proposal is
> to convert pg_tablespace to system view may be?
>

I don't see why it causes you so much trouble. You should already have
many locations in your code where you need to check the version to be
compatible with the latest major releases. I know pgAdmin does. So I
guess that one more is not a big deal.

And this change in PostgreSQL helps a lot DBAs who want to move
tablespaces (not really common work AFAIK, I agree).

--
Guillaume
http://blog.guillaume.lelarge.info
http://www.dalibo.com

Hello, Guillaume.

You wrote:

GL> Hi Pavel,

GL> On Mon, 2012-06-25 at 08:26 +0300, Pavel Golub wrote:
>> Hello, Pgsql-bugs.
>>
>> According to the "Moving tablespaces" thread started by Bruce
>> http://archives.postgresql.org/pgsql-docs/2011-12/msg00003.php
>> pg_tablespace.spclocation column is removed in the 9.2beta. However
>> this breaks backward compatibility for a bunch of products, e.g.
>> pgAdmin, phpPgAdmin, PgMDD etc.
>>
>> I'm not sure this is the best choice. Because each application with
>> tablespace support will need additional check now to determine what
>> way to use for obtaining tablespace location:
>> pg_get_tablespace_location(oid) or tablespace.spclocation
>>
>> I'm aware of problems caused by this hard coded column. My proposal is
>> to convert pg_tablespace to system view may be?
>>

GL> I don't see why it causes you so much trouble.

Not so much. However.

GL> You should already have
GL> many locations in your code where you need to check the version to be
GL> compatible with the latest major releases.

This is holy true.

GL> I know pgAdmin does. So I
GL> guess that one more is not a big deal.

GL> And this change in PostgreSQL helps a lot DBAs who want to move
GL> tablespaces (not really common work AFAIK, I agree).

I know. I just followed the advice of Josh Berkus and added this as a
bug.

--
With best wishes,
Pavel mailto:pavel(at)gf(dot)microolap(dot)com

Pavel Golub <pavel(at)microolap(dot)com> writes:
> I'm aware of problems caused by this hard coded column. My proposal is
> to convert pg_tablespace to system view may be?

It's not that easy to make a 100% backwards compatible view for a system
catalog. The main sticking point is the OID column; see recent problems
with pg_roles' OID column for an example. On the whole I don't think
renaming pg_tablespace and inserting a mostly-compatible view would be
a net advance.

More generally, I don't see that this particular incompatibility in
the system catalogs is worse than many others that we've perpetrated.

regards, tom lane

On Mon, Jun 25, 2012 at 3:46 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Pavel Golub <pavel(at)microolap(dot)com> writes:
>> I'm aware of problems caused by this hard coded column. My proposal is
>> to convert pg_tablespace to system view may be?
>
> It's not that easy to make a 100% backwards compatible view for a system
> catalog.  The main sticking point is the OID column; see recent problems
> with pg_roles' OID column for an example.  On the whole I don't think
> renaming pg_tablespace and inserting a mostly-compatible view would be
> a net advance.
>
> More generally, I don't see that this particular incompatibility in
> the system catalogs is worse than many others that we've perpetrated.

I'd say it's a lot less bad than some others. At least for this one
you can reasonably connect and figure it out. There was the changes
for database config, I think, which made at least pgadmin break even
before it managed to connect properly. (It got the connection in the
libpq sense, but not in the pgadmin sense).

Bottom line is, any admin tool will *always* have to have to know
about the specific versions and have code to deal with being able to
run different queries on different versions anyway. And this one is
trivial to reimplement with a different query, compared to most
others.

Yes, if we had a set of those stable-system-views that people keep
asking for every now and then, this is one of the few changes that
they *would* actually help with. But there would still be changes that
even those couldn't deal with, because they simply can't know the
future...

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/