Re: [COMMITTERS] pgsql: Second try committing the path changes.

Log Message:
-----------
Second try committing the path changes.

Modified Files:
--------------
pgsql/src/interfaces/ecpg/test:
pg_regress.sh (r1.8 -> r1.9)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/ecpg/test/pg_regress.sh.diff?r1=1.8&r2=1.9)
pgsql/src/interfaces/ecpg/test/expected:
compat_informix-dec_test.c (r1.6 -> r1.7)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/ecpg/test/expected/compat_informix-dec_test.c.diff?r1=1.6&r2=1.7)
compat_informix-rnull.c (r1.5 -> r1.6)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/ecpg/test/expected/compat_informix-rnull.c.diff?r1=1.5&r2=1.6)
compat_informix-test_informix.c (r1.5 -> r1.6)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/ecpg/test/expected/compat_informix-test_informix.c.diff?r1=1.5&r2=1.6)
compat_informix-test_informix2.c (r1.6 -> r1.7)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/ecpg/test/expected/compat_informix-test_informix2.c.diff?r1=1.6&r2=1.7)
complex-test1.c (r1.3 -> r1.4)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/ecpg/test/expected/complex-test1.c.diff?r1=1.3&r2=1.4)
complex-test2.c (r1.4 -> r1.5)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/ecpg/test/expected/complex-test2.c.diff?r1=1.4&r2=1.5)
complex-test3.c (r1.4 -> r1.5)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/ecpg/test/expected/complex-test3.c.diff?r1=1.4&r2=1.5)
complex-test4.c (r1.5 -> r1.6)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/ecpg/test/expected/complex-test4.c.diff?r1=1.5&r2=1.6)
complex-test5.c (r1.5 -> r1.6)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/ecpg/test/expected/complex-test5.c.diff?r1=1.5&r2=1.6)
connect-test2.c (r1.4 -> r1.5)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/ecpg/test/expected/connect-test2.c.diff?r1=1.4&r2=1.5)
connect-test3.c (r1.5 -> r1.6)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/ecpg/test/expected/connect-test3.c.diff?r1=1.5&r2=1.6)
connect-test4.c (r1.3 -> r1.4)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/ecpg/test/expected/connect-test4.c.diff?r1=1.3&r2=1.4)
errors-init.c (r1.6 -> r1.7)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/ecpg/test/expected/errors-init.c.diff?r1=1.6&r2=1.7)
pgtypeslib-dt_test.c (r1.7 -> r1.8)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/ecpg/test/expected/pgtypeslib-dt_test.c.diff?r1=1.7&r2=1.8)
pgtypeslib-dt_test2.c (r1.3 -> r1.4)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/ecpg/test/expected/pgtypeslib-dt_test2.c.diff?r1=1.3&r2=1.4)
pgtypeslib-num_test.c (r1.5 -> r1.6)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/ecpg/test/expected/pgtypeslib-num_test.c.diff?r1=1.5&r2=1.6)
pgtypeslib-num_test2.c (r1.8 -> r1.9)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/ecpg/test/expected/pgtypeslib-num_test2.c.diff?r1=1.8&r2=1.9)
sql-code100.c (r1.3 -> r1.4)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/ecpg/test/expected/sql-code100.c.diff?r1=1.3&r2=1.4)
sql-copystdout.c (r1.3 -> r1.4)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/ecpg/test/expected/sql-copystdout.c.diff?r1=1.3&r2=1.4)
sql-define.c (r1.3 -> r1.4)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/ecpg/test/expected/sql-define.c.diff?r1=1.3&r2=1.4)
sql-desc.c (r1.7 -> r1.8)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/ecpg/test/expected/sql-desc.c.diff?r1=1.7&r2=1.8)
sql-dynalloc.c (r1.5 -> r1.6)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/ecpg/test/expected/sql-dynalloc.c.diff?r1=1.5&r2=1.6)
sql-dynalloc2.c (r1.4 -> r1.5)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/ecpg/test/expected/sql-dynalloc2.c.diff?r1=1.4&r2=1.5)
sql-dyntest.c (r1.7 -> r1.8)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/ecpg/test/expected/sql-dyntest.c.diff?r1=1.7&r2=1.8)
sql-func.c (r1.3 -> r1.4)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/ecpg/test/expected/sql-func.c.diff?r1=1.3&r2=1.4)
sql-indicators.c (r1.3 -> r1.4)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/ecpg/test/expected/sql-indicators.c.diff?r1=1.3&r2=1.4)
sql-quote.c (r1.3 -> r1.4)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/ecpg/test/expected/sql-quote.c.diff?r1=1.3&r2=1.4)
sql-show.c (r1.3 -> r1.4)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/ecpg/test/expected/sql-show.c.diff?r1=1.3&r2=1.4)
thread-thread.c (r1.3 -> r1.4)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/ecpg/test/expected/thread-thread.c.diff?r1=1.3&r2=1.4)
thread-thread_implicit.c (r1.3 -> r1.4)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/ecpg/test/expected/thread-thread_implicit.c.diff?r1=1.3&r2=1.4)

meskes(at)postgresql(dot)org (Michael Meskes) writes:
> Second try committing the path changes.

Ah, this looks better. I get clean passes on both HPPA in-tree and
Fedora x86_64 VPATH builds, so I think you've finally fixed all the
issues. Congrats!

regards, tom lane

tgl(at)sss(dot)pgh(dot)pa(dot)us (Tom Lane) writes:
> meskes(at)postgresql(dot)org (Michael Meskes) writes:
>> Second try committing the path changes.
>
> Ah, this looks better. I get clean passes on both HPPA in-tree and
> Fedora x86_64 VPATH builds, so I think you've finally fixed all the
> issues. Congrats!

Ah. So this would have caused a bunch of problems in compiling
src/interfaces/ecpg/test/connect/test1.pgc???

I'm not sure I'm seeing it in CVS; perhaps this waits some time before
getting completely public?
--
let name="cbbrowne" and tld="ntlug.org" in name ^ "@" ^ tld;;
http://www3.sympatico.ca/cbbrowne/languages.html
"Unfortunately, because the wicked sorcerers of Silikonn' Vahlli hated
freedom, they devised clever signs and wonders to achieve the mighty
Captive User Interface, also known as the Prison for Idiot Minds."
-- Michael Peck <mjpeck(at)nstar(dot)net>

On 8/29/06, Chris Browne <cbbrowne(at)acm(dot)org> wrote:
> tgl(at)sss(dot)pgh(dot)pa(dot)us (Tom Lane) writes:
> > meskes(at)postgresql(dot)org (Michael Meskes) writes:
> >> Second try committing the path changes.
> >
> > Ah, this looks better. I get clean passes on both HPPA in-tree and
> > Fedora x86_64 VPATH builds, so I think you've finally fixed all the
> > issues. Congrats!
>
> Ah. So this would have caused a bunch of problems in compiling
> src/interfaces/ecpg/test/connect/test1.pgc???
>
> I'm not sure I'm seeing it in CVS; perhaps this waits some time before
> getting completely public?

i'm seeing this error when compiling HEAD (updated at ago 29 15:16)

make[5]: Entering directory
`/home/postgres/PG_RELEASES/pgsql-8.2uv/src/interfaces/ecpg/test/connect'
../../preproc/ecpg -I./../../include -o test1.c -I. test1.pgc
test1.pgc:29: ERROR: syntax error at or near "@"
make[5]: *** [test1.c] Error 3
make[5]: *** Deleting file `test1.c'

--
regards,
Jaime Casanova

"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs and the universe trying
to produce bigger and better idiots.
So far, the universe is winning."
Richard Cook

On Tue, Aug 29, 2006 at 03:35:14PM -0500, Jaime Casanova wrote:
> >Ah. So this would have caused a bunch of problems in compiling
> >src/interfaces/ecpg/test/connect/test1.pgc???

Not the compilation errors I would think.

> i'm seeing this error when compiling HEAD (updated at ago 29 15:16)
> ...

This looks like you're using an old version of the parser. preproc.y was
changed to handle empty database names and the the error you report is
due to an empty db name.

Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes(at)jabber(dot)org
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!

meskes(at)postgresql(dot)org (Michael Meskes) writes:
> On Tue, Aug 29, 2006 at 03:35:14PM -0500, Jaime Casanova wrote:
>> >Ah. So this would have caused a bunch of problems in compiling
>> >src/interfaces/ecpg/test/connect/test1.pgc???
>
> Not the compilation errors I would think.
>
>> i'm seeing this error when compiling HEAD (updated at ago 29 15:16)
>> ...
>
> This looks like you're using an old version of the parser. preproc.y was
> changed to handle empty database names and the the error you report is
> due to an empty db name.

I think the problem is that the latest version of preproc.c isn't
based on that version of preproc.y (or perhaps similarly with pgc.l/pgc.c).

If I touch preproc.y and pgc.l, the .c files get regenerated, and all
is well.

If I don't, they get left alone, and I see compilation errors.

It seems to me you need to rebuild the C files and commit them.
--
select 'cbbrowne' || '@' || 'ntlug.org';
http://www3.sympatico.ca/cbbrowne/lsf.html
When I die, I'd like to go peacefully in my sleep like my grandfather,
not screaming in terror like his passengers...

On 8/30/06, Michael Meskes <meskes(at)postgresql(dot)org> wrote:
> On Tue, Aug 29, 2006 at 03:35:14PM -0500, Jaime Casanova wrote:
> > i'm seeing this error when compiling HEAD (updated at ago 29 15:16)
> > ...
>
> This looks like you're using an old version of the parser. preproc.y was
> changed to handle empty database names and the the error you report is
> due to an empty db name.
>

seems, you are right... i had downloaded the entire CVS again and now
all is working fine

--
regards,
Jaime Casanova

"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs and the universe trying
to produce bigger and better idiots.
So far, the universe is winning."
Richard Cook

Chris Browne <cbbrowne(at)acm(dot)org> writes:
> If I touch preproc.y and pgc.l, the .c files get regenerated, and all
> is well.

> If I don't, they get left alone, and I see compilation errors.

> It seems to me you need to rebuild the C files and commit them.

No, because those derived files are not in CVS at all. What you
are describing sounds to me like a clock skew problem. Is your
machine's system clock showing the correct date?

regards, tom lane

tgl(at)sss(dot)pgh(dot)pa(dot)us (Tom Lane) writes:
> Chris Browne <cbbrowne(at)acm(dot)org> writes:
>> If I touch preproc.y and pgc.l, the .c files get regenerated, and all
>> is well.
>
>> If I don't, they get left alone, and I see compilation errors.
>
>> It seems to me you need to rebuild the C files and commit them.
>
> No, because those derived files are not in CVS at all. What you
> are describing sounds to me like a clock skew problem. Is your
> machine's system clock showing the correct date?

Odd, odd. NOT a clock problem. The .c files were sitting in my
buildfarm's CVS repository for HEAD. And yes, indeed, the derived
files shouldn't have been there at all. I'm not quite sure how they
got there in the first place.

At any rate, after comprehensively looking for yacc-derived files,
that clears this problem, as well as regression failures with last
night's commit of COPY (SELECT) TO, which is no bad thing.
--
(format nil "~S(at)~S" "cbbrowne" "ntlug.org")
http://www.ntlug.org/~cbbrowne/linux.html
Rules of the Evil Overlord #155. "If I know of any heroes in the land,
I will not under any circumstance kill their mentors, teachers, and/or
best friends." <http://www.eviloverlord.com/>

Chris Browne <cbbrowne(at)acm(dot)org> writes:
> tgl(at)sss(dot)pgh(dot)pa(dot)us (Tom Lane) writes:
>> No, because those derived files are not in CVS at all. What you
>> are describing sounds to me like a clock skew problem. Is your
>> machine's system clock showing the correct date?

> Odd, odd. NOT a clock problem. The .c files were sitting in my
> buildfarm's CVS repository for HEAD. And yes, indeed, the derived
> files shouldn't have been there at all. I'm not quite sure how they
> got there in the first place.

> At any rate, after comprehensively looking for yacc-derived files,
> that clears this problem, as well as regression failures with last
> night's commit of COPY (SELECT) TO, which is no bad thing.

I'll bet the way they got there is you did a build in the CVS repository
tree, and then cleaned up with "make distclean" not "make maintainer-clean".

The buildfarm script is supposed to complain about unexpected files in
the repository --- I wonder if it is fooled by the .cvsignore entries
for these files?

regards, tom lane

Tom Lane wrote:
> Chris Browne <cbbrowne(at)acm(dot)org> writes:
>
>> tgl(at)sss(dot)pgh(dot)pa(dot)us (Tom Lane) writes:
>>
>>> No, because those derived files are not in CVS at all. What you
>>> are describing sounds to me like a clock skew problem. Is your
>>> machine's system clock showing the correct date?
>>>
>
>
>> Odd, odd. NOT a clock problem. The .c files were sitting in my
>> buildfarm's CVS repository for HEAD. And yes, indeed, the derived
>> files shouldn't have been there at all. I'm not quite sure how they
>> got there in the first place.
>>
>
>
>> At any rate, after comprehensively looking for yacc-derived files,
>> that clears this problem, as well as regression failures with last
>> night's commit of COPY (SELECT) TO, which is no bad thing.
>>
>
> I'll bet the way they got there is you did a build in the CVS repository
> tree, and then cleaned up with "make distclean" not "make maintainer-clean".
>
> The buildfarm script is supposed to complain about unexpected files in
> the repository --- I wonder if it is fooled by the .cvsignore entries
> for these files?
>
> regards, tom lane
>
>

Yes, we do. A patch made in July 2005 has this comment:

"ignore files listed in cvsignore files - this will stop inappropriate triggering of vpath builds."

Perhaps I should only do that for vpath builds. Or perhaps I should even
remove them at the end of a build, since we don't expect any of those
files in a clean repo, do we?

Also, in case anyone has not got the message yet: Don't ever build by
hand in the buildfarm repo. Ever. I mean it. Use a copy.

cheers

andrew

Andrew Dunstan wrote:
> Tom Lane wrote:
>>
>> The buildfarm script is supposed to complain about unexpected files in
>> the repository --- I wonder if it is fooled by the .cvsignore entries
>> for these files?
>>
>
> Yes, we do. A patch made in July 2005 has this comment:
>
> "ignore files listed in cvsignore files - this will stop inappropriate
> triggering of vpath builds."
>
>
> Perhaps I should only do that for vpath builds. Or perhaps I should
> even remove them at the end of a build, since we don't expect any of
> those files in a clean repo, do we?
>
> Also, in case anyone has not got the message yet: Don't ever build by
> hand in the buildfarm repo. Ever. I mean it. Use a copy.
>
>

I have just committed a patch that removes the cvsignore trap. This
should be safe as we now remove them at the end of a buildfarm vpath run.

cheers

andrew

On Wed, Aug 30, 2006 at 12:48:55PM -0400, Chris Browne wrote:
> > This looks like you're using an old version of the parser. preproc.y was
> > changed to handle empty database names and the the error you report is
> > due to an empty db name.
>
> I think the problem is that the latest version of preproc.c isn't
> based on that version of preproc.y (or perhaps similarly with pgc.l/pgc.c).
> ...
> It seems to me you need to rebuild the C files and commit them.

AFAIRC the C files have never been part of the archive. The question is
why the new preproc.y didn't trigger a rebuild of preproc.c.

Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes(at)jabber(dot)org
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!