Is PG a moving target?

Ken,

* Ken Johanson (pg-user@kensystem.com) wrote:

But given the recent and dramatic example of 8.3's on-by-default stricter
typing in functions (now not-autocasting), I worry that kind of change
could happen in every minor version (8.4 etc).

8.3 isn't a minor version.

Enjoy,

Stephen

Stephen Frost wrote:

* Ken Johanson (pg-user@kensystem.com) wrote:

But given the recent and dramatic example of 8.3's on-by-default stricter
typing in functions (now not-autocasting), I worry that kind of change
could happen in every minor version (8.4 etc).

8.3 isn't a minor version.

PG uses a different versioning system than this one?:
http://en.wikipedia.org/wiki/Software_versioning#Numeric

Or do you mean the changes are not minor? :-)

Ken Johanson wrote:

Stephen Frost wrote:

* Ken Johanson (pg-user@kensystem.com) wrote:

But given the recent and dramatic example of 8.3's on-by-default
stricter typing in functions (now not-autocasting), I worry that kind
of change could happen in every minor version (8.4 etc).

8.3 isn't a minor version.

PG uses a different versioning system than this one?:
http://en.wikipedia.org/wiki/Software_versioning#Numeric

Or do you mean the changes are not minor? :-)

Yes, we use the one stated on our site, not wikipedia ;)

See: http://www.postgresql.org/support/versioning

It's also in our press FAQ (http://www.postgresql.org/about/press/faq),
but I can see how that's not the most natural place to look for it...

//Magnus

Magnus Hagander wrote:

PG uses a different versioning system than this one?:
http://en.wikipedia.org/wiki/Software_versioning#Numeric

Or do you mean the changes are not minor? :-)

Yes, we use the one stated on our site, not wikipedia ;)

See: http://www.postgresql.org/support/versioning

Thank you, I understand now.

"A major release is numbered by increasing either the first or second
part of the version number, e.g. 8.1 to 8.2."

On Sat, Feb 09, 2008 at 10:54:38AM -0700, Ken Johanson wrote:

Magnus Hagander wrote:

PG uses a different versioning system than this one?:
http://en.wikipedia.org/wiki/Software_versioning#Numeric

Or do you mean the changes are not minor? :-)

Yes, we use the one stated on our site, not wikipedia ;)
See: http://www.postgresql.org/support/versioning

Thank you, I understand now.

"A major release is numbered by increasing either the first or second part
of the version number, e.g. 8.1 to 8.2."

Josh has a great write up explenation as well

http://blogs.ittoolbox.com/database/soup/archives/guide-to-postgresql-version-numbers-19177

--
Curtis Gallant
cgallant@gmail.com

Ken Johanson wrote:

Magnus Hagander wrote:

PG uses a different versioning system than this one?:
http://en.wikipedia.org/wiki/Software_versioning#Numeric

Or do you mean the changes are not minor? :-)

Yes, we use the one stated on our site, not wikipedia ;)

See: http://www.postgresql.org/support/versioning

Thank you, I understand now.

"A major release is numbered by increasing either the first or second
part of the version number, e.g. 8.1 to 8.2."

Good.

That's not to say that your concerns aren't valid, btw. To answer your
original question, I haven't heard of a way to make it act like 8.2 wrt
the casting, because most people feel it's better to fix the issues in
the application than to apply band-aid.

And yes, similar things may happen for 8.4, but there's nothing out
there yet that we *know* will make such a change.

//Magnus

Ken Johanson <pg-user@kensystem.com> writes:

Is there anything now, or in the works, for compatibility emulation?

Sure: keep using the same major release. This is one of the reasons
that we keep updating back release branches for so long.

regards, tom lane

On Sat, 09 Feb 2008 10:20:51 -0700
Ken Johanson <pg-user@kensystem.com> wrote:

I acknowledge that from time to time we must accept changes in the
3rd party software that will break our apps if we (or customers) ever
upgrade them (a compounded issue if we have heavily-used deployments
in the field and not just in-house ones to maintain).

But given the recent and dramatic example of 8.3's on-by-default
stricter typing in functions (now not-autocasting), I worry that kind
of change could happen in every minor version (8.4 etc).

8.4 is a major release. 8.3.1 would be a minor release.

Joshua D. Drake

--
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL SPI Liaison | SPI Director | PostgreSQL political pundit

I noticed that, in one of the third-party databases I have installed
on my server, one foreign key constraint could not be implemented.
(The key columns are of incompatible types.) In previous upgrades I
had seen a warning concerning this constraint, and had passed this
information along to the people who maintain this database, but they
ignored it. Now the warnings have turned into an error, and the
constraint isn't being implemented.

So this is an issue I've been aware of for a long time (more than two
years, in fact), and if I'd been responsible for maintaining the
database, I would have fixed it long ago.

Maybe I'm overly optimistic, but I get the impression that, if you
pay attention to warnings and fix your problems in a timely manner,
you're unlikely to be blindsided when the rules get tightened up in
subsequent releases.

On Feb 10, 2008, at 10:44 AM, Dave Livesay wrote:

I noticed that, in one of the third-party databases I have
installed on my server, one foreign key constraint could not be
implemented. (The key columns are of incompatible types.) In
previous upgrades I had seen a warning concerning this constraint,
and had passed this information along to the people who maintain
this database, but they ignored it. Now the warnings have turned
into an error, and the constraint isn't being implemented.

So this is an issue I've been aware of for a long time (more than
two years, in fact), and if I'd been responsible for maintaining
the database, I would have fixed it long ago.

Maybe I'm overly optimistic, but I get the impression that, if you
pay attention to warnings and fix your problems in a timely manner,
you're unlikely to be blindsided when the rules get tightened up in
subsequent releases.

True, however, there was never a "transitional" release that issued
warning when using implicit type casts in expressions like (heh):
some_timestamp_field LIKE '2008-01-02%'. I think having a
transitionary period in which warnings were emitted or having the
ability to switch the casting behavior on and off, much like what was
done with backslash escaped strings, would have made the change much
more appealing. For large applications that used the implicit type
casts a lot (and I even remember the implicit timestamp to string
casting being recommended usage on this list) being able to turn the
behaviour on and off on a per-session basis would have made the
migration LOADS simpler.

Erik Jones

DBA | Emma®
erik@myemma.com
800.595.4401 or 615.292.5888
615.292.0777 (fax)

Emma helps organizations everywhere communicate & market in style.
Visit us online at http://www.myemma.com

Ken Johanson wrote:

Is there anything now, or in the works, for compatibility emulation? For
example to setup my session to act like 8.2 and allow less-strict
typing.

The best way to ensure 8.2 compatibility is to use 8.2. But as casts are user
definable, you can add back any casts you want. Just don't add dozens of
implicit casts and then come back here wondering why your application is
behaving strangely. :)

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

On Feb 9, 2008, at 12:20 PM, Ken Johanson wrote:

But given the recent and dramatic example of 8.3's on-by-default
stricter typing in functions (now not-autocasting), I worry that
kind of change could happen in every minor version (8.4 etc).

You need to *know* your software if you're using it production. 8.4
is *not* a minor version upgrade; it is a major upgrade. The Postgres
"guarantee" is that nothing will change in behavior on the 8.x branch
for a given x.

On Mon, 2008-02-11 at 09:09 +0100, Peter Eisentraut wrote:

Ken Johanson wrote:

Is there anything now, or in the works, for compatibility emulation? For
example to setup my session to act like 8.2 and allow less-strict
typing.

The best way to ensure 8.2 compatibility is to use 8.2. But as casts are user
definable, you can add back any casts you want. Just don't add dozens of
implicit casts and then come back here wondering why your application is
behaving strangely. :)

As I understand it, it's tricky (or impossible) to get the 8.2 behavior
back just by adding/modifying casts.

If not, couldn't we just publish those casts so people can be backwards
compatible if they want?

Regards,
Jeff Davis

On Monday 11 February 2008 14:49, Jeff Davis wrote:

On Mon, 2008-02-11 at 09:09 +0100, Peter Eisentraut wrote:

Ken Johanson wrote:

Is there anything now, or in the works, for compatibility emulation?
For example to setup my session to act like 8.2 and allow less-strict
typing.

The best way to ensure 8.2 compatibility is to use 8.2. But as casts are
user definable, you can add back any casts you want. Just don't add
dozens of implicit casts and then come back here wondering why your
application is behaving strangely. :)

As I understand it, it's tricky (or impossible) to get the 8.2 behavior
back just by adding/modifying casts.

If not, couldn't we just publish those casts so people can be backwards
compatible if they want?

that was the idea behind castcompat, which didn't get far out of the gate
before several examples cropped up showing how backwards-compatible casting
would break new 8.3 system expectations.

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