Thread: 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@gf.microolap.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@gf.microolap.com
Pavel Golub <pavel@microolap.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@sss.pgh.pa.us> wrote: > Pavel Golub <pavel@microolap.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/