I've tried the pg_dump bundled in the new 7.1.1 release. I wanted to
test its feature of dumping a 7.0.X database.

Let's say I have database A running 7.1.1, B running 7.0.2. Both servers
have the same database 'test', 'myview' is a view defined on both of
them. I want to dump data only, being a VIEW I expect zero rows.

 From host A:

pg_dump -da -t myview test	OK
pg_dump -h B -a -t myview test	OK
pg_dump -h B -da -t myview test	An INSERT for each row

This last behaviour is obviously wrong because you cannot re-INSERT into
the VIEW (no rules are defined).

 From host B:

pg_dump -da -t myview test	OK

Seems that there is a problem dumping 'INSERT-style' from a 7.0.X
database.

Running PostgreSQL 7.1.1 on alphaev67-dec-osf4.0f, compiled by cc -std

-- 
Alessio F. Bragadini		alessio@albourne.com
APL Financial Services		http://village.albourne.com
Nicosia, Cyprus		 	phone: +357-2-755750

"It is more complicated than you think"
		-- The Eighth Networking Truth from RFC 1925

Mon, 07 May 2001 13:19:48 +0300
Alessio Bragadini <alessio@albourne.com>
A problem with new pg_dump
At 13:19 7/05/01 +0300, Alessio Bragadini wrote:
>
>Seems that there is a problem dumping 'INSERT-style' from a 7.0.X
>database.
>

It's actually a more general problem - it looks like dumping views in 7.0
does not work with the 7.1.1 pg_dump (it thinks they are tables because the
7.1 check of pg_relkind='v' is not valid).



----------------------------------------------------------------
Philip Warner                    |     __---_____
Albatross Consulting Pty. Ltd.   |----/       -  \
(A.B.N. 75 008 659 498)          |          /(@)   ______---_
Tel: (+61) 0500 83 82 81         |                 _________  \
Fax: (+61) 0500 83 82 82         |                 ___________ |
Http://www.rhyme.com.au          |                /           \|
                                 |    --________--
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/

Mon, 07 May 2001 23:04:14 +1000
Philip Warner <pjw@rhyme.com.au>
Re: A problem with new pg_dump
At 23:04 7/05/01 +1000, Philip Warner wrote:
>
>It's actually a more general problem - it looks like dumping views in 7.0
>does not work with the 7.1.1 pg_dump (it thinks they are tables because the
>7.1 check of pg_relkind='v' is not valid).
>

The attached patch should fix the problem. Assuming it tests out OK, can
this be back-patched, since 7.1.1 is already out?




----------------------------------------------------------------
Philip Warner                    |     __---_____
Albatross Consulting Pty. Ltd.   |----/       -  \
(A.B.N. 75 008 659 498)          |          /(@)   ______---_
Tel: (+61) 0500 83 82 81         |                 _________  \
Fax: (+61) 0500 83 82 82         |                 ___________ |
Http://www.rhyme.com.au          |                /           \|
                                 |    --________--
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/
Mon, 07 May 2001 23:39:38 +1000
Philip Warner <pjw@rhyme.com.au>
Re: A problem with new pg_dump
Philip Warner <pjw@rhyme.com.au> writes:
> The attached patch should fix the problem. Assuming it tests out OK, can
> this be back-patched, since 7.1.1 is already out?

Yes, it should be back-patched into the REL7_1_STABLE branch once you're
confident of it.  Probably there will be a 7.1.2 by and by ...

Do you need a quick lecture on CVS branch management?

			regards, tom lane

Mon, 07 May 2001 11:22:53 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: A problem with new pg_dump 
At 11:22 7/05/01 -0400, Tom Lane wrote:
>
>Do you need a quick lecture on CVS branch management?
>

That would be sensible.


----------------------------------------------------------------
Philip Warner                    |     __---_____
Albatross Consulting Pty. Ltd.   |----/       -  \
(A.B.N. 75 008 659 498)          |          /(@)   ______---_
Tel: (+61) 0500 83 82 81         |                 _________  \
Fax: (+61) 0500 83 82 82         |                 ___________ |
Http://www.rhyme.com.au          |                /           \|
                                 |    --________--
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/

Tue, 08 May 2001 08:44:55 +1000
Philip Warner <pjw@rhyme.com.au>
Re: A problem with new pg_dump 
Philip Warner <pjw@rhyme.com.au> writes:
> At 11:22 7/05/01 -0400, Tom Lane wrote:
>> Do you need a quick lecture on CVS branch management?

> That would be sensible.

OK, some quick notes for those with commit privileges:

If you just do basic "cvs checkout", "cvs update", "cvs commit", then
you'll always be dealing with the HEAD version of the files in CVS.
That's what you want for development, but if you need to patch past
stable releases then you have to be able to access and update the
"branch" portions of our CVS repository.  We normally fork off a branch
for a stable release just before starting the development cycle for the
next release.

The first thing you have to know is the branch name for the branch you
are interested in getting at.  Unfortunately Marc has been less than
100% consistent in naming the things.  One way to check is to apply
"cvs log" to any file that goes back a long time, for example HISTORY
in the top directory:

$ cvs log HISTORY | more

RCS file: /home/projects/pgsql/cvsroot/pgsql/HISTORY,v
Working file: HISTORY
head: 1.106
branch:
locks: strict
access list:
symbolic names:
        REL7_1_STABLE: 1.106.0.2
        REL7_1_BETA: 1.79
        REL7_1_BETA3: 1.86
        REL7_1_BETA2: 1.86
        REL7_1: 1.102
        REL7_0_PATCHES: 1.70.0.2
        REL7_0: 1.70
        REL6_5_PATCHES: 1.52.0.2
        REL6_5: 1.52
        REL6_4: 1.44.0.2
        release-6-3: 1.33
        SUPPORT: 1.1.1.1
        PG95-DIST: 1.1.1
keyword substitution: kv
total revisions: 129;   selected revisions: 129
More---q

Unfortunately "cvs log" isn't all that great about distinguishing
branches from tags --- it calls 'em all "symbolic names".  (A "tag" just
marks a specific timepoint across all files --- it's essentially a
snapshot whereas a branch is a changeable fileset.)  Rule of thumb is
that names attached to four-number versions where the third number is
zero represent branches, the others are just tags.  Here we can see that
the extant branches are
	REL7_1_STABLE
	REL7_0_PATCHES
	REL6_5_PATCHES
The next commit to the head will be revision 1.107, whereas any changes
committed into the REL7_1_STABLE branch will have revision numbers like
1.106.2.*, corresponding to the branch number 1.106.0.2 (don't ask where
the zero went...).

OK, so how do you do work on a branch?  By far the best way is to create
a separate checkout tree for the branch and do your work in that.  Not
only is that the easiest way to deal with CVS, but you really need to
have the whole past tree available anyway to test your work.  (And you
*better* test your work.  Never forget that dot-releases tend to go out
with very little beta testing --- so whenever you commit an update to a
stable branch, you'd better be doubly sure that it's correct.)

Normally, to checkout the head branch, you just cd to the place you
want to contain the toplevel "pgsql" directory and say

	cvs ... checkout pgsql

To get a past branch, you cd to whereever you want it and say

	cvs ... checkout -r BRANCHNAME pgsql

For example, just a couple days ago I did

	mkdir ~postgres/REL7_1
	cd ~postgres/REL7_1
	cvs ... checkout -r REL7_1_STABLE pgsql

and now I have a maintenance copy of 7.1.*.

When you've done a checkout in this way, the branch name is "sticky":
CVS automatically knows that this directory tree is for the branch,
and whenever you do "cvs update" or "cvs commit" in this tree, you'll
fetch or store the latest version in the branch, not the head version.
Easy as can be.

So, if you have a patch that needs to apply to both the head and a
recent stable branch, you have to make the edits and do the commit
twice, once in your development tree and once in your stable branch
tree.  This is kind of a pain, which is why we don't normally fork
the tree right away after a major release --- we wait for a dot-release
or two, so that we won't have to double-patch the first wave of fixes.

Any questions?  (See the CVS manual for details on these commands,
of course.)

			regards, tom lane

Mon, 07 May 2001 19:35:03 -0400
Tom Lane <tgl@sss.pgh.pa.us>
CVS branch management (was Re: A problem with new pg_dump)
Tom Lane <tgl@sss.pgh.pa.us> writes:

> Unfortunately "cvs log" isn't all that great about distinguishing
> branches from tags --- it calls 'em all "symbolic names".

Minor addition to this: you can distinguish branches and tags by using
`cvs status -v'.

(Historical note: CVS was originally implemented as shell scripts on
top of RCS.  The .0 syntax was magic which CVS used to indicate a
branch as opposed to a revision tag.  The output of `cvs log' is
simply the output of `rlog' on the underlying RCS file.  `cvs status'
is not based on an existing RCS command.)

Ian

---------------------------(end of broadcast)---------------------------
TIP 734: Often statistics are used as a drunken man uses lampposts --
for support rather than illumination.

07 May 2001 18:45:13 -0700
Ian Lance Taylor <ian@airs.com>
Re: CVS branch management (was Re: A problem with new pg_dump)
> Any questions?  (See the CVS manual for details on these commands,
> of course.)

Would someone like to integrate this into the docs appendix which
already discusses the CVS repository?

                     - Thomas

Thu, 10 May 2001 14:21:08 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: CVS branch management (was Re: A problem with new pg_dump)

I have added this to the developer's FAQ.

---------------------------------------------------------------------------

> Philip Warner <pjw@rhyme.com.au> writes:
> > At 11:22 7/05/01 -0400, Tom Lane wrote:
> >> Do you need a quick lecture on CVS branch management?
> 
> > That would be sensible.
> 
> OK, some quick notes for those with commit privileges:
> 
> If you just do basic "cvs checkout", "cvs update", "cvs commit", then
> you'll always be dealing with the HEAD version of the files in CVS.
> That's what you want for development, but if you need to patch past
> stable releases then you have to be able to access and update the
> "branch" portions of our CVS repository.  We normally fork off a branch
> for a stable release just before starting the development cycle for the
> next release.
> 
> The first thing you have to know is the branch name for the branch you
> are interested in getting at.  Unfortunately Marc has been less than
> 100% consistent in naming the things.  One way to check is to apply
> "cvs log" to any file that goes back a long time, for example HISTORY
> in the top directory:
> 
> $ cvs log HISTORY | more
> 
> RCS file: /home/projects/pgsql/cvsroot/pgsql/HISTORY,v
> Working file: HISTORY
> head: 1.106
> branch:
> locks: strict
> access list:
> symbolic names:
>         REL7_1_STABLE: 1.106.0.2
>         REL7_1_BETA: 1.79
>         REL7_1_BETA3: 1.86
>         REL7_1_BETA2: 1.86
>         REL7_1: 1.102
>         REL7_0_PATCHES: 1.70.0.2
>         REL7_0: 1.70
>         REL6_5_PATCHES: 1.52.0.2
>         REL6_5: 1.52
>         REL6_4: 1.44.0.2
>         release-6-3: 1.33
>         SUPPORT: 1.1.1.1
>         PG95-DIST: 1.1.1
> keyword substitution: kv
> total revisions: 129;   selected revisions: 129
> More---q
> 
> Unfortunately "cvs log" isn't all that great about distinguishing
> branches from tags --- it calls 'em all "symbolic names".  (A "tag" just
> marks a specific timepoint across all files --- it's essentially a
> snapshot whereas a branch is a changeable fileset.)  Rule of thumb is
> that names attached to four-number versions where the third number is
> zero represent branches, the others are just tags.  Here we can see that
> the extant branches are
> 	REL7_1_STABLE
> 	REL7_0_PATCHES
> 	REL6_5_PATCHES
> The next commit to the head will be revision 1.107, whereas any changes
> committed into the REL7_1_STABLE branch will have revision numbers like
> 1.106.2.*, corresponding to the branch number 1.106.0.2 (don't ask where
> the zero went...).
> 
> OK, so how do you do work on a branch?  By far the best way is to create
> a separate checkout tree for the branch and do your work in that.  Not
> only is that the easiest way to deal with CVS, but you really need to
> have the whole past tree available anyway to test your work.  (And you
> *better* test your work.  Never forget that dot-releases tend to go out
> with very little beta testing --- so whenever you commit an update to a
> stable branch, you'd better be doubly sure that it's correct.)
> 
> Normally, to checkout the head branch, you just cd to the place you
> want to contain the toplevel "pgsql" directory and say
> 
> 	cvs ... checkout pgsql
> 
> To get a past branch, you cd to whereever you want it and say
> 
> 	cvs ... checkout -r BRANCHNAME pgsql
> 
> For example, just a couple days ago I did
> 
> 	mkdir ~postgres/REL7_1
> 	cd ~postgres/REL7_1
> 	cvs ... checkout -r REL7_1_STABLE pgsql
> 
> and now I have a maintenance copy of 7.1.*.
> 
> When you've done a checkout in this way, the branch name is "sticky":
> CVS automatically knows that this directory tree is for the branch,
> and whenever you do "cvs update" or "cvs commit" in this tree, you'll
> fetch or store the latest version in the branch, not the head version.
> Easy as can be.
> 
> So, if you have a patch that needs to apply to both the head and a
> recent stable branch, you have to make the edits and do the commit
> twice, once in your development tree and once in your stable branch
> tree.  This is kind of a pain, which is why we don't normally fork
> the tree right away after a major release --- we wait for a dot-release
> or two, so that we won't have to double-patch the first wave of fixes.
> 
> Any questions?  (See the CVS manual for details on these commands,
> of course.)
> 
> 			regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Tue, 27 Nov 2001 13:25:37 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: CVS branch management (was Re: A problem with new pg_dump)

I have added a mention of 'cvs status -v' to the developer's FAQ, with
your name on it.

---------------------------------------------------------------------------

> Tom Lane <tgl@sss.pgh.pa.us> writes:
> 
> > Unfortunately "cvs log" isn't all that great about distinguishing
> > branches from tags --- it calls 'em all "symbolic names".
> 
> Minor addition to this: you can distinguish branches and tags by using
> `cvs status -v'.
> 
> (Historical note: CVS was originally implemented as shell scripts on
> top of RCS.  The .0 syntax was magic which CVS used to indicate a
> branch as opposed to a revision tag.  The output of `cvs log' is
> simply the output of `rlog' on the underlying RCS file.  `cvs status'
> is not based on an existing RCS command.)
> 
> Ian
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 734: Often statistics are used as a drunken man uses lampposts --
> for support rather than illumination.
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Tue, 27 Nov 2001 13:26:03 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: CVS branch management (was Re: A problem with new pg_dump)
> > Any questions?  (See the CVS manual for details on these commands,
> > of course.)
> 
> Would someone like to integrate this into the docs appendix which
> already discusses the CVS repository?

I added these to the developer's FAQ.  The seem a little detailed for
the main docs.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Tue, 27 Nov 2001 13:26:35 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: CVS branch management (was Re: A problem with new pg_dump)
Bruce Momjian writes:

> I added these to the developer's FAQ.  The seem a little detailed for
> the main docs.

I was always under the impression that a FAQ was an *abbreviated* version
of some of the main docs.  As in, FAQ = frequently asked questions, main
docs = all possible questions.  So this reasoning doesn't make sense to
me.

-- 
Peter Eisentraut   peter_e@gmx.net


Wed, 28 Nov 2001 21:48:42 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
Re: CVS branch management (was Re: A problem with new
> Bruce Momjian writes:
> 
> > I added these to the developer's FAQ.  The seem a little detailed for
> > the main docs.
> 
> I was always under the impression that a FAQ was an *abbreviated* version
> of some of the main docs.  As in, FAQ = frequently asked questions, main
> docs = all possible questions.  So this reasoning doesn't make sense to
> me.

I guess informal would be a better word for what I added.  They are more
impressions or tips.  Do we want to formalize them by putting them in
the docs?  I am glad to add them.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Wed, 28 Nov 2001 16:00:03 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: CVS branch management (was Re: A problem with new pg_dump)
On Wednesday 28 November 2001 03:48 pm, Peter Eisentraut wrote:
> Bruce Momjian writes:
> > I added these to the developer's FAQ.  The seem a little detailed for
> > the main docs.

> I was always under the impression that a FAQ was an *abbreviated* version
> of some of the main docs.  As in, FAQ = frequently asked questions, main
> docs = all possible questions.  So this reasoning doesn't make sense to
> me.

FAQ = questions from users on how the thing works, with answers gleaned 
fromthe developer's mailing list (this has been the definition for at least 
ten years -- or more -- but, as I've only been internet-literate for a mere 
ten years, I wouldn't have first-hand knowledge of accepted practice prior to 
1991.  As I ran a C-News site beginning in 1991, I got up to speed on the 
Jargon fairly quickly.  Speaking of Jargon.... according to Jargoogle, FAQ is 
'officially':
"FAQ /F-A-Q/ or /fak/ n. 

[Usenet] 1. A Frequently Asked Question. 2. A compendium of accumulated lore, 
posted periodically to high-volume newsgroups in an attempt to forestall such 
questions. Some people prefer the term `FAQ list' or `FAQL' /fa'kl/, 
reserving `FAQ' for sense 1. 

This lexicon itself serves as a good example of a collection of one kind of 
lore, although it is far too big for a regular FAQ posting. Examples: "What 
is the proper type of NULL?" and "What's that funny name for the # 
character?" are both Frequently Asked Questions. Several FAQs refer readers 
to this file. "

So, while Bruce isn't doing the regular list posting of the dev FAQ, it still 
is a compendium in sense 2....)

docs = our take on the questions we think will be asked about how the thing 
works, plus any FAQL's necessary.

While it may seem to be hairsplitting, the traditional FAQ list is just 
exactly what Bruce has developed in the developers FAQ -- these are answers 
that currently don't fit in our docs in an organized fashion.  Now, maybe if 
the docs were modified to include this information... (hint, hint)....
-- 
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Wed, 28 Nov 2001 16:22:18 -0500
Lamar Owen <lamar.owen@wgcr.org>
Re: CVS branch management (was Re: A problem with new
On Wed, 28 Nov 2001, Lamar Owen wrote:

> > I was always under the impression that a FAQ was an *abbreviated* version
> > of some of the main docs.  As in, FAQ = frequently asked questions, main
> > docs = all possible questions.  So this reasoning doesn't make sense to
> > me.
>
> FAQ = questions from users on how the thing works, with answers gleaned
> fromthe developer's mailing list (this has been the definition for at least
> ten years -- or more -- but, as I've only been internet-literate for a mere
> ten years, I wouldn't have first-hand knowledge of accepted practice prior to
> 1991.  As I ran a C-News site beginning in 1991, I got up to speed on the
> Jargon fairly quickly.  Speaking of Jargon.... according to Jargoogle, FAQ is

I've seen them (that I recall) back to at least '72 and the definition is
still the same as yours Lamar.

> 'officially':
> "FAQ /F-A-Q/ or /fak/ n.

'cept we pronounced it different.  Two sylables, the second only being
the Q.  I think you get the idea.  I won't go into the rationale for it
tho.

Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH    email: vev@michvhf.com    http://www.pop4.net
         56K Nationwide Dialup from $16.00/mo at Pop4 Networking
        Online Campground Directory    http://www.camping-usa.com
       Online Giftshop Superstore    http://www.cloudninegifts.com
==========================================================================




Wed, 28 Nov 2001 17:23:48 -0500 (EST)
Vince Vielhaber <vev@michvhf.com>
Re: CVS branch management (was Re: A problem with new