Thread: Is PG a moving target?
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). Sure the strict-typing (and other compatibility-breaking changes) is a good thing in the long run, but it discourages anyone trying to: a) port apps from another database b) upgrade PG to get other features, or port apps written against from a PG version that's 1 year older The type-strictness change, as an example, also creates pragmatic vs academic (polarizing) debates around "rtrim(intype)" being innocuous vs sloppy. And "database XYZ is better/worse", e.g balance of ease of use, TCO, vs ACID, strictness etc). The word 'balance' is key. 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. Or can one write an app against 8.3 and safely assume that 8.4 *could* also add more behavior changes (e.g even more strict-ness in functions where even 8.3 could be *validly argued* as being too loose)?... Ken
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
Attachment
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
Attachment
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