pg_class.relistemp

David E. Wheeler wrote:

Hackers,

With regard to this change:

http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=5f7b58fad8f45c69bb67944779dce67e2f481995

I'm wondering if it would be possible to restore the relistemp column
to pg_class, at least for backwards compatibility, so that apps that
expected it can continue to work on both 9.0 and 9.1. Even if it's
read-only somehow, and the same as `relpersistence <> 't'`.

Uh, that is going to require an initdb, and it is unlinkely we are going
to need that this far into 9.1 beta. Also, we don't normally keep
system table columns around for backward compatibility because of the
confusion it can cause, e.g. which column do I look at?

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

On Jul 13, 2011, at 12:14 PM, Bruce Momjian wrote:

I'm wondering if it would be possible to restore the relistemp column
to pg_class, at least for backwards compatibility, so that apps that
expected it can continue to work on both 9.0 and 9.1. Even if it's
read-only somehow, and the same as `relpersistence <> 't'`.

Uh, that is going to require an initdb, and it is unlinkely we are going
to need that this far into 9.1 beta.

I was afraid of that.

Also, we don't normally keep
system table columns around for backward compatibility because of the
confusion it can cause, e.g. which column do I look at?

The one that's documented.

Wasn't newsysviews supposed to deal with these sorts of issues? Why were they rejected?

Best,

David

David E. Wheeler wrote:

On Jul 13, 2011, at 12:14 PM, Bruce Momjian wrote:

I'm wondering if it would be possible to restore the relistemp column
to pg_class, at least for backwards compatibility, so that apps that
expected it can continue to work on both 9.0 and 9.1. Even if it's
read-only somehow, and the same as `relpersistence <> 't'`.

Uh, that is going to require an initdb, and it is unlinkely we are going
to need that this far into 9.1 beta.

I was afraid of that.

Also, we don't normally keep
system table columns around for backward compatibility because of the
confusion it can cause, e.g. which column do I look at?

The one that's documented.

Well, that assumes people read the documention and don't just do \d.
Keeping cruft around over time makes the system more complex.

Wasn't newsysviews supposed to deal with these sorts of issues? Why
were they rejected?

No idea.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

Excerpts from Bruce Momjian's message of mié jul 13 15:24:35 -0400 2011:

David E. Wheeler wrote:

On Jul 13, 2011, at 12:14 PM, Bruce Momjian wrote:

I'm wondering if it would be possible to restore the relistemp column
to pg_class, at least for backwards compatibility, so that apps that
expected it can continue to work on both 9.0 and 9.1. Even if it's
read-only somehow, and the same as `relpersistence <> 't'`.

Uh, that is going to require an initdb, and it is unlinkely we are going
to need that this far into 9.1 beta.

I was afraid of that.

Also, we don't normally keep
system table columns around for backward compatibility because of the
confusion it can cause, e.g. which column do I look at?

The one that's documented.

Well, that assumes people read the documention and don't just do \d.
Keeping cruft around over time makes the system more complex.

This seems a case where column synonyms would have been useful (as was
the procpid / pid change).

--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

On Jul 13, 2011, at 12:38 PM, Alvaro Herrera wrote:

Well, that assumes people read the documention and don't just do \d.
Keeping cruft around over time makes the system more complex.

This seems a case where column synonyms would have been useful (as was
the procpid / pid change).

Well it couldn't just be that, because the data type has changed, too. Unless you could make a kind of "view column" or something where the expression was `relpersistence <> 't'`.

Best,

David

"David E. Wheeler" <david@kineticode.com> wrote:

Unless you could make a kind of "view column" or something where the

expression was `relpersistence <> 't'`.

create or replace function relistemp(rel pg_class)
returns boolean language sql immutable strict as
$$select $1.relpersistence = 't';$$;

Just don't forget to use the table name or alias in front of it... :-)

-Kevin

On Jul 13, 2011, at 12:57 PM, Kevin Grittner wrote:

create or replace function relistemp(rel pg_class)
returns boolean language sql immutable strict as
$$select $1.relpersistence = 't';$$;

Just don't forget to use the table name or alias in front of it... :-)

Oh, nice hack. How far back does that work (pgTAP runs on 8.0 and higher)?

Thanks,

David

On 14.07.2011 19:51, David E. Wheeler wrote:

On Jul 13, 2011, at 12:57 PM, Kevin Grittner wrote:

create or replace function relistemp(rel pg_class)
returns boolean language sql immutable strict as
$$select $1.relpersistence = 't';$$;

Just don't forget to use the table name or alias in front of it... :-)

Oh, nice hack. How far back does that work (pgTAP runs on 8.0 and higher)?

Far back. But you only need it in >= 9.1. Older versions have the
pg_class.relistemp column anyway.

Not sure how this helps, though. If you modify pgTAP to install that
automatically in pgTAP when dealing with a new server version, you might
as well modify its queries to use relispersistence = 't' directly when
dealing with a new server version. It works as a manual work-around if
you can't upgrade pgTAP, I guess.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

"David E. Wheeler" <david@kineticode.com> wrote:

On Jul 13, 2011, at 12:57 PM, Kevin Grittner wrote:

create or replace function relistemp(rel pg_class)
returns boolean language sql immutable strict as
$$select $1.relpersistence = 't';$$;

Just don't forget to use the table name or alias in front of
it... :-)

Oh, nice hack. How far back does that work (pgTAP runs on 8.0 and
higher)?

As far as I know, the technique of creating a function with a record
type as its only parameter to use as a "generated column" goes way
back. This particular function won't work prior to 9.1, because you
won't have the relpersistence column, but then, prior to 9.1 you
wouldn't need to run this because you already have a relistemp
column.

-Kevin

On Jul 14, 2011, at 9:55 AM, Heikki Linnakangas wrote:

Far back. But you only need it in >= 9.1. Older versions have the pg_class.relistemp column anyway.

Yeah.

Not sure how this helps, though. If you modify pgTAP to install that automatically in pgTAP when dealing with a new server version, you might as well modify its queries to use relispersistence = 't' directly when dealing with a new server version. It works as a manual work-around if you can't upgrade pgTAP, I guess.

Yeah, that's what I'd rather avoid. I'll probably have to modify the function that makes the call to look at the version number. Annoying, but do-able.

https://github.com/theory/pgtap/blob/master/sql/pgtap.sql.in#L5894

Best,

David

All,

BTW, if we're dumping relistemp, we're going to need to notify every
maker of a PostgreSQL admin interface before we release 9.1.

This is why we should have had a complete set of sysviews ...

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

Josh Berkus wrote:

All,

BTW, if we're dumping relistemp, we're going to need to notify every
maker of a PostgreSQL admin interface before we release 9.1.

This is why we should have had a complete set of sysviews ...

Are they not testing our 9.1 betas?

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

Bruce Momjian <bruce@momjian.us> writes:

Josh Berkus wrote:

BTW, if we're dumping relistemp, we're going to need to notify every
maker of a PostgreSQL admin interface before we release 9.1.

Are they not testing our 9.1 betas?

There has never, ever, been a guarantee that the system catalogs don't
change across versions. Anybody issuing such queries should expect to
have to retest them and possibly change them in each new major release.
I see nothing to sweat about here.

regards, tom lane

On Jul 14, 2011, at 12:19 PM, Tom Lane wrote:

Are they not testing our 9.1 betas?

There has never, ever, been a guarantee that the system catalogs don't
change across versions. Anybody issuing such queries should expect to
have to retest them and possibly change them in each new major release.
I see nothing to sweat about here.

A deprecation cycle at least might be useful.

Best,

David

"David E. Wheeler" <david@kineticode.com> wrote:

A deprecation cycle at least might be useful.

How about a "relistemp" extension on pgxn.org for the "generated
column" function to provide the backward compatibility? Is the new
extension mechanism a sane way to help those who need a phase-out
period?

-Kevin

There has never, ever, been a guarantee that the system catalogs don't
change across versions. Anybody issuing such queries should expect to
have to retest them and possibly change them in each new major release.

I know that's always been our policy. It his, however,
vendor-unfriendly because we don't supply any interface for many things
(such as temp tables) other than the system catalogs.

So if we're going to break compatibility, then we could stand to make a
little noise about it.

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

On Thu, Jul 14, 2011 at 21:59, Josh Berkus <josh@agliodbs.com> wrote:

There has never, ever, been a guarantee that the system catalogs don't
change across versions.  Anybody issuing such queries should expect to
have to retest them and possibly change them in each new major release.

I know that's always been our policy.  It his, however,
vendor-unfriendly because we don't supply any interface for many things
(such as temp tables) other than the system catalogs.

So if we're going to break compatibility, then we could stand to make a
little noise about it.

We've broken the admin apps in pretty much every single release. And
they generally don't complain. If someone developing an admin app
hasn't been doing extensive testing starting *at the latest* with
beta1 (and recommended per each alpha), they shouldn't expect to
release until quite long after the release.

That said, a stable set of system views certainly wouldn't hurt - but
making extra noise about a simple change like this one would likely
not make a difference.

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

On Thursday, July 14, 2011, Josh Berkus <josh@agliodbs.com> wrote:

There has never, ever, been a guarantee that the system catalogs don't
change across versions.  Anybody issuing such queries should expect to
have to retest them and possibly change them in each new major release.

I know that's always been our policy.  It his, however,
vendor-unfriendly because we don't supply any interface for many things
(such as temp tables) other than the system catalogs.

So if we're going to break compatibility, then we could stand to make a
little noise about it.

As one of said vendors, I completely disagree. There are a ton of
things that change with each release, and all we do by putting in
hacks for backwards compatibility is add bloat that needs to be
maintained, and encourage vendors to be lazy.

Break compatibility is actually something that is important to us - it
forces us to fix obvious issues, and makes it much harder to
inadvertently miss important changes.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Jul 14, 2011, at 2:10 PM, Dave Page wrote:

Break compatibility is actually something that is important to us - it
forces us to fix obvious issues, and makes it much harder to
inadvertently miss important changes.

Agreed, but a deprecation cycle would be much appreciated.

David