Backward compatibility? Never heard of it!

Playing with fresh PostgreSQL 9.2beta2 I cannot find spclocation column of a system catalog pg_tablespace. First my thought was that I’m too tired. But then I found mentioning about this at pgsql-hackers by Magnus Hagander:

And IIRC, we don’t actually *use* spclocation anywhere. How about we
just get rid of them as independents?

Oh, really?!!! WTF? How about other developers, ha? I’m using this. I really do. Don’t know how about other guys, but I will need additional nasty checks for server version to know what should I use: pg_get_tablespace_location(oid) or tablespace.spclocation

Thanks a lot guys! Way to go!

About these ads

Nerd.

Tagged with: , , ,
Posted in PostgreSQL
10 comments on “Backward compatibility? Never heard of it!
  1. Anonymous says:

    The catalog structure was never promised to be stable, so if you’re relying on them you need to test with each major version and be prepared for breakage. And the release notes mention that pg_tablespace.spclocation is gone.

    Maybe you could create a function my_tablespace_location that either looks at pg_tablespace.spclocation or dispatches to pg_tablespace_location() and this way have a backwards compatibility layer in your code?

  2. depeszsz says:

    Out of curiosity – what are you using this for?

  3. jma says:

    Well, it’s not just you. Both pgAdmin and phpPgAdmin show the location for tablespaces too.

  4. Josh Berkus says:

    9.2 is still in beta. File a bug.

    • pashagolub says:

      Even if this issue already added to the release notes?

      • Josh Berkus says:

        Yes. Often when we remove stuff like this it’s based on the idea that nobody is using it for anything important. If people report application breakage, then often incompatible changes are phased in over more than one release, i.e. marked obsolete for 2 releases, then removed.

        This is also evidence that we need a set of stable, comprehensive system views separate from the system tables, which is a long-term windmill I’ve been tilting at since 8.4. So I’d love to see you file a bug for that reason too.

  5. Seems no one commented about _why_ it was removed. We already had a symbolic link that points to the tablespace location, and the removal of this column makes it possible to cleanly change the location of those symlinks while the server is down, with no other adjustments required.

    This is all mentioned in the release note item, which somehow was not read in this case. The Postgres developers are not as inept as this blog post suggests.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Archives
Map of wandering
Follow

Get every new post delivered to your Inbox.

Join 78 other followers

%d bloggers like this: