If you run 6.5 pg_dump against a 7.0 database, or vice versa,
you get very obscure error messages:
parseNumericArray: too many numbers
getInherits(): SELECT failed. Explanation from backend: 'ERROR: Attribute 'inhrel' not found
(Quick, guess which is which ... you'll probably guess wrong.)

It's too late to do anything about the behavior of 6.5 pg_dump,
but we could change 7.0 and later pg_dump to check the database
version at startup and refuse to run if it's not the expected value.

A downside is that a pg_dump might refuse to dump a DB that it actually
would work with; that could be a pain in the neck, particularly in
development scenarios where you might not have kept the previous
compilation of pg_dump lying around. Yet I think I prefer that to the
risk of an insidious incompatibility that causes pg_dump to run without
complaint yet generate a bogus dump.

Comments anyone?

regards, tom lane

Search Discussions

  • The Hermit Hacker at Apr 3, 2000 at 7:03 pm

    On Mon, 3 Apr 2000, Tom Lane wrote:

    If you run 6.5 pg_dump against a 7.0 database, or vice versa,
    you get very obscure error messages:
    parseNumericArray: too many numbers
    getInherits(): SELECT failed. Explanation from backend: 'ERROR: Attribute 'inhrel' not found
    (Quick, guess which is which ... you'll probably guess wrong.)

    It's too late to do anything about the behavior of 6.5 pg_dump,
    but we could change 7.0 and later pg_dump to check the database
    version at startup and refuse to run if it's not the expected value.

    A downside is that a pg_dump might refuse to dump a DB that it actually
    would work with; that could be a pain in the neck, particularly in
    development scenarios where you might not have kept the previous
    compilation of pg_dump lying around. Yet I think I prefer that to the
    risk of an insidious incompatibility that causes pg_dump to run without
    complaint yet generate a bogus dump.

    Comments anyone?
    Sounds reasonable to me ...
  • Alfred Perlstein at Apr 3, 2000 at 7:08 pm

    * Tom Lane [000403 12:18] wrote:
    If you run 6.5 pg_dump against a 7.0 database, or vice versa,
    you get very obscure error messages:
    parseNumericArray: too many numbers
    getInherits(): SELECT failed. Explanation from backend: 'ERROR: Attribute 'inhrel' not found
    (Quick, guess which is which ... you'll probably guess wrong.)

    It's too late to do anything about the behavior of 6.5 pg_dump,
    but we could change 7.0 and later pg_dump to check the database
    version at startup and refuse to run if it's not the expected value.

    A downside is that a pg_dump might refuse to dump a DB that it actually
    would work with; that could be a pain in the neck, particularly in
    development scenarios where you might not have kept the previous
    compilation of pg_dump lying around. Yet I think I prefer that to the
    risk of an insidious incompatibility that causes pg_dump to run without
    complaint yet generate a bogus dump.

    Comments anyone?
    It's a great idea and later down the road the versioning information
    could be used to determine if it's actually possible to pg_dump
    with a certain version, ie the pg_dump program can report its
    version number to postgresql and postgresql can reply if it thinks
    it's compatible with the version of pg_dump being used.

    --
    -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
    "I have the heart of a child; I keep it in a jar on my desk."
  • Tom Lane at Apr 4, 2000 at 5:23 am

    Ed Loehr writes:
    How about a pg_dump "force" option to run regardless of potential
    incompatibilities?
    Good idea --- done.

    regards, tom lane
  • Tom Lane at Apr 4, 2000 at 2:42 pm

    Peter Eisentraut writes:
    A downside is that a pg_dump might refuse to dump a DB that it actually
    would work with;
    Well, the fact remains that 6.5 (and probably earlier) pg_dump doesn't
    work with 7.0 databases unless you fix the getInherits() function to do
    different things with different backends. Or what did you mean with "would
    actually work"?
    I was just speculating about possible future problems. Given the code
    I committed last night, a 7.0 pg_dump will refuse to run with a 7.1
    database (or vice versa, unless we change the version-checking code
    before 7.1 is released). Now maybe that combination would have worked
    anyway --- but we don't know yet.

    I did put in a switch to override the version check, so if you know it
    will work you can use that switch.

    regards, tom lane

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedApr 3, '00 at 6:48p
activeApr 4, '00 at 2:42p
posts5
users3
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2021 Grokbase