It seems current source is broken if MB is enabled.

gcc -c  -I../../../src/interfaces/libpq -I../../../src/include  -I../../../src/interfaces/libpq -O2 -Wall -Wmissing-prototypes -Wmissing-declarations pg_dump.c -o pg_dump.o
pg_dump.c: In function `isViewRule':
pg_dump.c:267: parse error before `int'
pg_dump.c:268: `len' undeclared (first use in this function)
pg_dump.c:268: (Each undeclared identifier is reported only once
pg_dump.c:268: for each function it appears in.)
pg_dump.c:268: warning: implicit declaration of function `pg_mbcliplen'
make[3]: *** [pg_dump.o] Error 1

The problem is:

#ifdef MULTIBYTE
	int len;
	len = pg_mbcliplen(rulename,strlen(rulename),NAMEDATALEN-1);
	rulename[len] = '\0';
#else
	:
	:

Moreover, pg_mbcliplen cannot be used in frontend. It seems what we
need here is new backendside functiontion what does same as
pg_mbcliplen. Will look into this...
--
Tatsuo Ishii

Wed, 13 Sep 2000 13:07:22 +0900
Tatsuo Ishii <t-ishii@sra.co.jp>
current is broken
Tatsuo Ishii <t-ishii@sra.co.jp> writes:
> It seems current source is broken if MB is enabled.
> gcc -c  -I../../../src/interfaces/libpq -I../../../src/include  -I../../../src/interfaces/libpq -O2 -Wall -Wmissing-prototypes -Wmissing-declarations pg_dump.c -o pg_dump.o
> pg_dump.c: In function `isViewRule':
> pg_dump.c:267: parse error before `int'

I just fixed one of these in the backend --- looks like someone was
testing with a C++ compiler instead of an ANSI-C-compliant compiler.
Need to put the 'int len;' declaration at the top of the function.

> pg_dump.c:268: warning: implicit declaration of function `pg_mbcliplen'

> Moreover, pg_mbcliplen cannot be used in frontend.

Ooops.  I guess libpq needs to supply a copy of this function?

			regards, tom lane

Wed, 13 Sep 2000 00:35:15 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: current is broken 
> I just fixed one of these in the backend --- looks like someone was
> testing with a C++ compiler instead of an ANSI-C-compliant compiler.
> Need to put the 'int len;' declaration at the top of the function.

Ok.

> > pg_dump.c:268: warning: implicit declaration of function `pg_mbcliplen'
> 
> > Moreover, pg_mbcliplen cannot be used in frontend.
> 
> Ooops.  I guess libpq needs to supply a copy of this function?

Simply copying the function won't work since the way to know what
encoding is used for this session is different between backend and
frontend.

Even better idea would be creating a new function that returns the
actual rule name (after being shorten) from given view name. I don't
think it's a good idea to have codes to get an actual rule name in two
separate places.
--
Tatsuo Ishii

Wed, 13 Sep 2000 13:56:46 +0900
Tatsuo Ishii <t-ishii@sra.co.jp>
Re: current is broken 
Tatsuo Ishii <t-ishii@sra.co.jp> writes:
>> Ooops.  I guess libpq needs to supply a copy of this function?

> Simply copying the function won't work since the way to know what
> encoding is used for this session is different between backend and
> frontend.

Good point --- in fact, the encoding itself might be different between
the backend and frontend.  That seems to imply that "truncate to
NAMEDATALEN bytes" could yield different results in the frontend than
what the backend would get.

> Even better idea would be creating a new function that returns the
> actual rule name (after being shorten) from given view name. I don't
> think it's a good idea to have codes to get an actual rule name in two
> separate places.

Given the above point about encoding differences, I think we *must*
do the truncation in the backend ...

			regards, tom lane

Wed, 13 Sep 2000 01:02:51 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: current is broken 
> -----Original Message-----
> From: Tom Lane
> 
> Tatsuo Ishii <t-ishii@sra.co.jp> writes:
> >> Ooops.  I guess libpq needs to supply a copy of this function?
> 
> > Simply copying the function won't work since the way to know what
> > encoding is used for this session is different between backend and
> > frontend.
> 
> Good point --- in fact, the encoding itself might be different between
> the backend and frontend.  That seems to imply that "truncate to
> NAMEDATALEN bytes" could yield different results in the frontend than
> what the backend would get.
> 
> > Even better idea would be creating a new function that returns the
> > actual rule name (after being shorten) from given view name. I don't
> > think it's a good idea to have codes to get an actual rule name in two
> > separate places.
> 
> Given the above point about encoding differences, I think we *must*
> do the truncation in the backend ...
>

I agree with Tatsuo.
However we already have relkind for views.
Why must we rely on rulename to implement isViewRule()
in the first place ? 

Regards.

Hiroshi Inoue

Wed, 13 Sep 2000 14:31:51 +0900
"Hiroshi Inoue" <Inoue@tpf.co.jp>
RE: current is broken 
At 13:07 13/09/00 +0900, Tatsuo Ishii wrote:
>It seems current source is broken if MB is enabled.
>
>gcc -c  -I../../../src/interfaces/libpq -I../../../src/include
-I../../../src/interfaces/libpq -O2 -Wall -Wmissing-prototypes
-Wmissing-declarations pg_dump.c -o pg_dump.o
>pg_dump.c: In function `isViewRule':
>pg_dump.c:267: parse error before `int'
>pg_dump.c:268: `len' undeclared (first use in this function)
>pg_dump.c:268: (Each undeclared identifier is reported only once
>pg_dump.c:268: for each function it appears in.)
>pg_dump.c:268: warning: implicit declaration of function `pg_mbcliplen'
>make[3]: *** [pg_dump.o] Error 1
>

I haven't looked at the code yet, but isViewRule is going to change to use
the new reltype for views. Maybe this will side-step the problem?


----------------------------------------------------------------
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   |/

Wed, 13 Sep 2000 15:44:25 +1000
Philip Warner <pjw@rhyme.com.au>
Re: current is broken
> > Good point --- in fact, the encoding itself might be different between
> > the backend and frontend.  That seems to imply that "truncate to
> > NAMEDATALEN bytes" could yield different results in the frontend than
> > what the backend would get.
> > 
> > > Even better idea would be creating a new function that returns the
> > > actual rule name (after being shorten) from given view name. I don't
> > > think it's a good idea to have codes to get an actual rule name in two
> > > separate places.
> > 
> > Given the above point about encoding differences, I think we *must*
> > do the truncation in the backend ...
> >
> 
> I agree with Tatsuo.
> However we already have relkind for views.
> Why must we rely on rulename to implement isViewRule()
> in the first place ? 

Oh, I forgot about that.

BTW, does anybody know about the status of pg_dump? It seems tons of
features have been added, but I wonder if all of them are going to
appear in 7.1.  Especially now it seems to have an ability to dump
Blobs, but the flag (-b) to enable the feature has been disabled. Why?
--
Tatsuo Ishii

Wed, 13 Sep 2000 19:41:36 +0900
Tatsuo Ishii <t-ishii@sra.co.jp>
RE: current is broken 
> >BTW, does anybody know about the status of pg_dump? It seems tons of
> >features have been added, but I wonder if all of them are going to
> >appear in 7.1.  Especially now it seems to have an ability to dump
> >Blobs, but the flag (-b) to enable the feature has been disabled. Why?
> 
> Is it? AFAIK, it should not have been disabled. The long params version is
> --blob - does that work?

Ok, long params works. It seems just adding 'b' to the third argument
of getopt() solves "-b" option problem. Do you wnat to fix by yourself?

> Personally, I'd like to see them in 7.1, unless the testing period
> reveals a swag of major flaws...  Once CVS is up again, I intend to
> do a little more work on pg_dump, so now would be a good time to let
> me know if there are problems.

New pg_dump looks great. Could you add docs for it so that we can test
it out?
--
Tatsuo Ishii

Wed, 13 Sep 2000 21:35:28 +0900
Tatsuo Ishii <t-ishii@sra.co.jp>
RE: current is broken 
At 19:41 13/09/00 +0900, Tatsuo Ishii wrote:
>
>BTW, does anybody know about the status of pg_dump? It seems tons of
>features have been added, but I wonder if all of them are going to
>appear in 7.1.  Especially now it seems to have an ability to dump
>Blobs, but the flag (-b) to enable the feature has been disabled. Why?

Is it? AFAIK, it should not have been disabled. The long params version is
--blob - does that work?

Personally, I'd like to see them in 7.1, unless the testing period reveals
a swag of major flaws...

Once CVS is up again, I intend to do a little more work on pg_dump, so now
would be a good time to let me know if there are problems.


----------------------------------------------------------------
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   |/

Wed, 13 Sep 2000 22:41:37 +1000
Philip Warner <pjw@rhyme.com.au>
RE: current is broken 
> >New pg_dump looks great. Could you add docs for it so that we can test
> >it out?
> It's on the list - I'm still waiting for an upgrade to Framemaker, since I
> can't stomach raw SGML. If it doesn't arrive soon, I'll just have to do it
> the hard way.

If necessary, you can type straight into the existing docs without doing
much about markup, and I'll fix up the sgml tags later.

afaik I've never seen sgml from FM; it will be interesting to see how it
turns out.

                      - Thomas

Wed, 13 Sep 2000 13:42:40 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: current is broken
At 21:35 13/09/00 +0900, Tatsuo Ishii wrote:
>> >BTW, does anybody know about the status of pg_dump? It seems tons of
>> >features have been added, but I wonder if all of them are going to
>> >appear in 7.1.  Especially now it seems to have an ability to dump
>> >Blobs, but the flag (-b) to enable the feature has been disabled. Why?
>> 
>> Is it? AFAIK, it should not have been disabled. The long params version is
>> --blob - does that work?
>
>Ok, long params works. It seems just adding 'b' to the third argument
>of getopt() solves "-b" option problem. Do you wnat to fix by yourself?

May as well, since I'll be doing some other stuff.


>> Personally, I'd like to see them in 7.1, unless the testing period
>> reveals a swag of major flaws...  Once CVS is up again, I intend to
>> do a little more work on pg_dump, so now would be a good time to let
>> me know if there are problems.
>
>New pg_dump looks great. Could you add docs for it so that we can test
>it out?

It's on the list - I'm still waiting for an upgrade to Framemaker, since I
can't stomach raw SGML. If it doesn't arrive soon, I'll just have to do it
the hard way.





----------------------------------------------------------------
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   |/

Thu, 14 Sep 2000 00:17:02 +1000
Philip Warner <pjw@rhyme.com.au>
RE: current is broken 
On Wed, Sep 13, 2000 at 03:44:25PM +1000, Philip Warner wrote:
> At 13:07 13/09/00 +0900, Tatsuo Ishii wrote:
> >It seems current source is broken if MB is enabled.

Gah, I Was afraid of this. My patch, I'm afraid.

> >
> 
> I haven't looked at the code yet, but isViewRule is going to change to use
> the new reltype for views. Maybe this will side-step the problem?
> 

Yes, it should. However, I've just done a quick test in a non-MB compile, and
it looks like char(n) = 'a string constant' returns true if the first n chars
match. If this is correct behavior, and holds in the multibyte case, then
you can strip out _all_ the rulename truncation from pg_dump.
Here's the example:

I've got a view named: " this_is_a_really_really_long_vi", with matching rule:
"_RETthis_is_a_really_really_lon"

Without truncation, pgdump generates (with addition of relname for
readability) this query (hand wrapped)

reedstrm=# select relname,rulename from pg_class, pg_rewrite 
           where pg_class.oid = ev_class and pg_rewrite.ev_type = '1' 
           and rulename = '_RETthis_is_a_really_really_long_vi';

             relname             |            rulename             
---------------------------------+---------------------------------
 this_is_a_really_really_long_vi | _RETthis_is_a_really_really_lon
(1 row)

reedstrm=# 


Ross
-- 
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu> 
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St.,  Houston, TX 77005

Thu, 14 Sep 2000 17:40:57 -0500
"Ross J. Reedstrom" <reedstrm@rice.edu>
Re: current is broken
> -----Original Message-----
> From: Ross J. Reedstrom
> 
> On Wed, Sep 13, 2000 at 03:44:25PM +1000, Philip Warner wrote:
> > At 13:07 13/09/00 +0900, Tatsuo Ishii wrote:
> > >It seems current source is broken if MB is enabled.
> 
> Gah, I Was afraid of this. My patch, I'm afraid.
> 
> > >
> > 
> > I haven't looked at the code yet, but isViewRule is going to 
> change to use
> > the new reltype for views. Maybe this will side-step the problem?
> > 
> 
> Yes, it should. However, I've just done a quick test in a non-MB 
> compile, and
> it looks like char(n) = 'a string constant' returns true if the 
> first n chars
> match. If this is correct behavior, and holds in the multibyte case, then
> you can strip out _all_ the rulename truncation from pg_dump.

Isn't it a problem of backend side ?
It seems quite strange to me that clients should/could assume
such a complicated rule. I was surprized to see how many 
applications have used complicated(but incomplete in some
cases) definiton(criterion ?)s of views to see if a table is a
view. 
Now we have a relkind for views and in addtion haven't we
already had pg_views view to encapsulate the definition of
views. 

Regards.

Hiroshi Inoue

Fri, 15 Sep 2000 10:40:13 +0900
"Hiroshi Inoue" <Inoue@tpf.co.jp>
RE: current is broken
Philip Warner <pjw@rhyme.com.au> writes:
> The only thing that's missing is a 'rulekind' for rules - it would be very
> nice if pg_dump could use a simple method (that didn't involve munging
> names) to determin is a rule is a 'view rule'.

Oh, I finally see the problem: when you come to dump out the rules, you
need to avoid dumping the rules that correspond to views because you're
going to emit the CREATE VIEW commands separately.

You don't really need a rulekind though.  If it's an ON SELECT rule for
a relation that you've determined to be a view, then the rule is a
view rule.  Otherwise, you print the rule.

			regards, tom lane

Thu, 14 Sep 2000 22:23:12 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: current is broken 
> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> 
> Philip Warner <pjw@rhyme.com.au> writes:
> > The only thing that's missing is a 'rulekind' for rules - it 
> would be very
> > nice if pg_dump could use a simple method (that didn't involve munging
> > names) to determin is a rule is a 'view rule'.
> 
> Oh, I finally see the problem: when you come to dump out the rules, you
> need to avoid dumping the rules that correspond to views because you're
> going to emit the CREATE VIEW commands separately.
> 
> You don't really need a rulekind though.  If it's an ON SELECT rule for
> a relation that you've determined to be a view, then the rule is a
> view rule.  Otherwise, you print the rule.
>

Is it guaranteed that ON SELECT rule is unique per view in the future ?

Regards.

Hiroshi Inoue

Fri, 15 Sep 2000 11:36:16 +0900
"Hiroshi Inoue" <Inoue@tpf.co.jp>
RE: current is broken 
At 10:40 15/09/00 +0900, Hiroshi Inoue wrote:
>
>Now we have a relkind for views and in addtion haven't we
>already had pg_views view to encapsulate the definition of
>views. 
>

The only thing that's missing is a 'rulekind' for rules - it would be very
nice if pg_dump could use a simple method (that didn't involve munging
names) to determin is a rule is a 'view rule'.



----------------------------------------------------------------
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   |/

Fri, 15 Sep 2000 12:44:52 +1000
Philip Warner <pjw@rhyme.com.au>
RE: current is broken
At 22:23 14/09/00 -0400, Tom Lane wrote:
>
>Oh, I finally see the problem: when you come to dump out the rules, you
>need to avoid dumping the rules that correspond to views because you're
>going to emit the CREATE VIEW commands separately.
>
>You don't really need a rulekind though.  If it's an ON SELECT rule for
>a relation that you've determined to be a view, then the rule is a
>view rule.  Otherwise, you print the rule.
>

It looks like some nice person has defined the 'pg_rules' view which does
not return rules used in views. I'll try using this since it removes
another layer of backend knowledge from pg_dump.





----------------------------------------------------------------
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   |/

Fri, 15 Sep 2000 14:16:43 +1000
Philip Warner <pjw@rhyme.com.au>
Re: current is broken 

I've now committed the latest pg_dump. The following is the list of changes:

- Support for relkind = RELKIND_VIEW.
- Use symbols for tests on relkind (ie. use RELKIND_VIEW, not 'v')
- Fix bug in support for -b option (== --blobs).
- Dump views as views (using 'create view').
- Remove 'isViewRule' since we check the relkind when getting tables.
- Now uses temp table 'pgdump_oid' rather than 'pg_dump_oid' (errors
otherwise).
- Added extra param for specifying handling of OID=0 and which typename to
output.
- Fixed bug in SQL scanner when SQL contained braces. (in rules)
- Use format_type function wherever possible

It works on all my DBs, and on the regression DB, so I am at least mildly
optimistic. The main issue that I think might arise are from the use of
format_type in function definitions. It's easy to change if we have to go
back to using typname.


----------------------------------------------------------------
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   |/

Fri, 15 Sep 2000 15:43:25 +1000
Philip Warner <pjw@rhyme.com.au>
New pg_dump committed...
> Done. Do you know often the web-based version of the documentation get
> updated?

Should be twice a day. afaik you can go to hub.org:~thomas/CURRENT and
run ./docbuild. Make sure your umask is set to 2 (so I can update files
after that) and you may want to detach the command and log it to a file
since it will take 5-10min to run.

                       - Thomas

Wed, 18 Oct 2000 13:55:43 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: pg_dump docs
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
>> Done. Do you know often the web-based version of the documentation get
>> updated?

> Should be twice a day.

Where is this auto-updated copy hiding?  The bookmark I have,
	http://www.postgresql.org/docs/postgres/index.html
is pointing at files that haven't updated for months...

			regards, tom lane

Wed, 18 Oct 2000 13:28:52 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Re: pg_dump docs 
> > Should be twice a day.
> Where is this auto-updated copy hiding?  The bookmark I have,
>         http://www.postgresql.org/docs/postgres/index.html
> is pointing at files that haven't updated for months...

Right. Last updated at the last release.

The developer's versions from the current tree are at

  http://www.postgresql.org/devel-corner/docs/postgres

(and admin,programmer,tutorial,user)

I don't see a reference from the developer's corner web page, which
seems to point back to the released version instead.

                       - Thomas

Thu, 19 Oct 2000 04:39:00 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: Re: pg_dump docs
On Thu, 19 Oct 2000, Thomas Lockhart wrote:

> > > Should be twice a day.
> > Where is this auto-updated copy hiding?  The bookmark I have,
> >         http://www.postgresql.org/docs/postgres/index.html
> > is pointing at files that haven't updated for months...
> 
> Right. Last updated at the last release.
> 
> The developer's versions from the current tree are at
> 
>   http://www.postgresql.org/devel-corner/docs/postgres
> 
> (and admin,programmer,tutorial,user)
> 
> I don't see a reference from the developer's corner web page, which
> seems to point back to the released version instead.

That's strange... I see it :)       ...now

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




Thu, 19 Oct 2000 05:56:27 -0400 (EDT)
Vince Vielhaber <vev@michvhf.com>
Re: Re: pg_dump docs
> > I don't see a reference from the developer's corner web page, which
> > seems to point back to the released version instead.
> That's strange... I see it :)       ...now

Great! But I don't, maybe due to caching somewhere? Should I be seeing 

  http://www.postgresql.org/devel-corner/
    -> Current documentation

pointing at

  http://www.postgresql.org/devel-corner/docs/index.html

(afaik this index.html does not yet exist, but could point to the
various flavors of pages and tarballs) rather than

  http://www.postgresql.org/docs/index.html

which is what I see now?

                      - Thomas

Thu, 19 Oct 2000 13:16:55 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: Re: pg_dump docs
On Thu, 19 Oct 2000, Thomas Lockhart wrote:

> > > I don't see a reference from the developer's corner web page, which
> > > seems to point back to the released version instead.
> > That's strange... I see it :)       ...now
> 
> Great! But I don't, maybe due to caching somewhere? Should I be seeing 
> 
>   http://www.postgresql.org/devel-corner/
>     -> Current documentation
> 
> pointing at
> 
>   http://www.postgresql.org/devel-corner/docs/index.html
> 
> (afaik this index.html does not yet exist, but could point to the
> various flavors of pages and tarballs) rather than
> 
>   http://www.postgresql.org/docs/index.html
> 
> which is what I see now?

I thought /docs/index.html was to be for the current docs.  Since they're
not, what ARE they pointing to??   Anyway, I've now got it pointing to
devel-contrib/docs/index.html and created an index.  If you ever need to 
update the index, look at the script makeindex in that directory.

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




Thu, 19 Oct 2000 11:13:03 -0400 (EDT)
Vince Vielhaber <vev@michvhf.com>
Re: Re: pg_dump docs
On Fri, 20 Oct 2000, Thomas Lockhart wrote:

> Vince Vielhaber wrote:
> > 
> > On Thu, 19 Oct 2000, Thomas Lockhart wrote:
> > 
> > > > > I don't see a reference from the developer's corner web page, which
> > > > > seems to point back to the released version instead.
> > > > That's strange... I see it :)       ...now
> > >
> > > Great! But I don't, maybe due to caching somewhere? Should I be seeing
> > >
> > >   http://www.postgresql.org/devel-corner/
> > >     -> Current documentation
> > >
> > > pointing at
> > >
> > >   http://www.postgresql.org/devel-corner/docs/index.html
> > >
> > > (afaik this index.html does not yet exist, but could point to the
> > > various flavors of pages and tarballs) rather than
> > >
> > >   http://www.postgresql.org/docs/index.html
> > >
> > > which is what I see now?
> > 
> > I thought /docs/index.html was to be for the current docs.  Since they're
> > not, what ARE they pointing to??   Anyway, I've now got it pointing to
> > devel-contrib/docs/index.html and created an index.  If you ever need to
> > update the index, look at the script makeindex in that directory.
> 
> docs/index.html *are* the "current docs". They correspond to the current
> released version, which would be 7.0.x (though it is possible that no
> one updated them for 7.0.2).
> 
> For developers (-hackers developers, not application developers using
> the current release), the "current docs" correspond to the docs built
> nightly (actually twice a day), which reflect the current development
> tree.

I see the problem.  You're not of BSD and I was thinking you were.  I'm 
guessing Marc is catching on right now.   To me, "current" means the
docs that correspond to the current (or development) code.  The release
I refer to is either stable or (more appropriately) "release" docs.

Either way, I think I have things figured out now.

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




Thu, 19 Oct 2000 22:14:04 -0400 (EDT)
Vince Vielhaber <vev@michvhf.com>
Re: Re: pg_dump docs
Vince Vielhaber wrote:
> 
> On Thu, 19 Oct 2000, Thomas Lockhart wrote:
> 
> > > > I don't see a reference from the developer's corner web page, which
> > > > seems to point back to the released version instead.
> > > That's strange... I see it :)       ...now
> >
> > Great! But I don't, maybe due to caching somewhere? Should I be seeing
> >
> >   http://www.postgresql.org/devel-corner/
> >     -> Current documentation
> >
> > pointing at
> >
> >   http://www.postgresql.org/devel-corner/docs/index.html
> >
> > (afaik this index.html does not yet exist, but could point to the
> > various flavors of pages and tarballs) rather than
> >
> >   http://www.postgresql.org/docs/index.html
> >
> > which is what I see now?
> 
> I thought /docs/index.html was to be for the current docs.  Since they're
> not, what ARE they pointing to??   Anyway, I've now got it pointing to
> devel-contrib/docs/index.html and created an index.  If you ever need to
> update the index, look at the script makeindex in that directory.

docs/index.html *are* the "current docs". They correspond to the current
released version, which would be 7.0.x (though it is possible that no
one updated them for 7.0.2).

For developers (-hackers developers, not application developers using
the current release), the "current docs" correspond to the docs built
nightly (actually twice a day), which reflect the current development
tree.

                     - Thomas

Fri, 20 Oct 2000 02:15:56 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: Re: pg_dump docs
At 11:13 19/10/00 -0400, Vince Vielhaber wrote:
>
>I thought /docs/index.html was to be for the current docs.  Since they're
>not, what ARE they pointing to??   Anyway, I've now got it pointing to
>devel-contrib/docs/index.html and created an index.  If you ever need to 
>update the index, look at the script makeindex in that directory.
>

I looks like all the HTML links on
http://www.postgresql.org/devel-corner/docs/index.html seem to be broken.


----------------------------------------------------------------
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   |/

Fri, 20 Oct 2000 13:07:42 +1000
Philip Warner <pjw@rhyme.com.au>
Re: Re: pg_dump docs
On Fri, 20 Oct 2000, Philip Warner wrote:

> At 11:13 19/10/00 -0400, Vince Vielhaber wrote:
> >
> >I thought /docs/index.html was to be for the current docs.  Since they're
> >not, what ARE they pointing to??   Anyway, I've now got it pointing to
> >devel-contrib/docs/index.html and created an index.  If you ever need to 
> >update the index, look at the script makeindex in that directory.
> >
> 
> I looks like all the HTML links on
> http://www.postgresql.org/devel-corner/docs/index.html seem to be broken.

oops!  Fixed.

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




Thu, 19 Oct 2000 23:39:46 -0400 (EDT)
Vince Vielhaber <vev@michvhf.com>
Re: Re: pg_dump docs
> [Not to list]

Back on list; thanks though for protecting me from ridicule ;)

> >For developers (-hackers developers, not application developers using
> >the current release), the "current docs" correspond to the docs built
> >nightly (actually twice a day), which reflect the current development
> >tree.
> If http://www.postgresql.org/devel-corner/docs/user/ is supposed to be
> based on CVS, then I must have done something wrong; the new pg_restore
> entry has not appeared (it's now > 24 hours old).
> Any hints would be appreciated.

Ah, the build has been failing for at least the last few days due to
small problems in new content. Since I receive ~700 logs of doc builds
each year (well, that is the annual rate but I've only stepped up to
twice daily since ~April), I get sloppy about looking through them
carefully, and instead tend to look for the *length* of the log as a
measure of success while rarely examining the end of the log to see how
it actually went. In this case I missed the failure.

btw, the build log is updated and posted at

  http://www.postgresql.org/devel-corner/docs/docbuild.log

Vince, could we get a cross reference to this on the developer's page?


The current problem is in using underscores in the "id" field of header
tags; this is an illegal character in this context per DocBook (a
feature not at all obvious, but which can be seen by omission in our
other docs).

pg_restore.sgml also had quite a few ^M's at the end of lines; I've got
a utility to clean those up so I applied those fixes also.

While tracking down another problem with replicated ID fields in
runtime.sgml, I caught a duplicated section and removed the apparently
older version.

I've also applied a couple of fixes suggested by Laser Henry.

Things now build without errors on my local machine, and should do the
same on postgresql.org.

                      - Thomas

Fri, 20 Oct 2000 14:21:06 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: Re: pg_dump docs
On Fri, 20 Oct 2000, Thomas Lockhart wrote:

> Ah, the build has been failing for at least the last few days due to
> small problems in new content. Since I receive ~700 logs of doc builds
> each year (well, that is the annual rate but I've only stepped up to
> twice daily since ~April), I get sloppy about looking through them
> carefully, and instead tend to look for the *length* of the log as a
> measure of success while rarely examining the end of the log to see how
> it actually went. In this case I missed the failure.
> 
> btw, the build log is updated and posted at
> 
>   http://www.postgresql.org/devel-corner/docs/docbuild.log
> 
> Vince, could we get a cross reference to this on the developer's page?

I was gonna ask you if you wanted that.  Anyway it's now there.  And
before anyone says it, yes I know about the duplicate link. :)

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




Fri, 20 Oct 2000 11:51:00 -0400 (EDT)
Vince Vielhaber <vev@michvhf.com>
Re: Re: pg_dump docs