Re: 7.4beta4: make check broken?

Pgadmin 3.1 don t work (operations like insert rows) with columns named
in russian language (title of column in russian language). But the same
operations using PhpPgAdmin - all works very well, right. And if
replace russian title of column with equivalent in english - all works
very well. PgAdmin responds the message: "2003-10-03 14:15:15 ERROR
: Column not found in pgSet: еще_колонка". Operation System: Windows
XP, distribution binary (zip), language russian.

Alexandr S wrote:

> Pgadmin 3.1 don t work (operations like insert rows) with columns
> named in russian language (title of column in russian language). But
> the same operations using PhpPgAdmin - all works very well, right.
> And if replace russian title of column with equivalent in english -
> all works very well. PgAdmin responds the message: "2003-10-03
> 14:15:15 ERROR : Column not found in pgSet: еще_колонка". Operation
> System: Windows XP, distribution binary (zip), language russian.
>
Hi Alexandr,

you're on the wrong list, please use pgadmin-support for pgAdmin related
questions.

Which tool did you use to insert the data?

Regards,
Andreas

Hi Andreas.

I take the report that it looks like this in Japan.
It was a problem with Windows.
There is patch which I suggested before.
It is important though this was ignored.
See it again.

OT)
My server is in bad condition, and I haven't been able to talk well since yesterday.
:-(

regards,
Hiroshi Saito

From: "Andreas Pflug" <pgadmin(at)pse-consulting(dot)de>

> Alexandr S wrote:
>
> > Pgadmin 3.1 don t work (operations like insert rows) with columns
> > named in russian language (title of column in russian language). But
> > the same operations using PhpPgAdmin - all works very well, right.
> > And if replace russian title of column with equivalent in english -
> > all works very well. PgAdmin responds the message: "2003-10-03
> > 14:15:15 ERROR : Column not found in pgSet: еще_колонка". Operation
> > System: Windows XP, distribution binary (zip), language russian.
> >
> Hi Alexandr,
>
> you're on the wrong list, please use pgadmin-support for pgAdmin related
> questions.
>
> Which tool did you use to insert the data?
>
> Regards,
> Andreas

Hi,
the following configure/make batch with postgresql-7.4beta4
results with the error below.
That is to say, make does work fine,
but make check results in an error. Oviously the target-directory
given with prefix is already used in some way with make check
(when make install is not yet run). This error did not occur with 7.3
versions, where the make test seemed to restrict itself to the source
directory and did not touch the target directory given by prefix.
The OS is Suse 8.2 with bison updated to 1.85 as required because of a
resp. warning from configure.

SourceDir="/usr/local/src/postgresql-7.4beta4"
TargetDir="/opt/doka/"
PORTNR=5432
export LC_LANG=de_DE(at)euro
export LC_COLLATE=de_DE
datum=`date +%d%b%Y_%H%M`
make clean
./configure --prefix=$TargetDir/pgsql \
--enable-nls='de' \
--with-pgport=$PORTNR \
--with-tcl \
--with-odbc \
--with-perl \
--with-openssl \
--with-python
make check

This did result in the following ...
============== removing existing temp installation ==============
============== creating temporary installation ==============
============== initializing database system ==============
============== starting postmaster ==============
running on port 65432 with pid 48
============== creating database "regression" ==============
/usr/local/src/postgresql-7.4beta4/src/test/regress/./tmp_check/install//opt/doka//pgsql/bin/createdb:
relocation error:
/us/local/src/postgresql-7.4beta4/src/test/regress/./tmp_check/install//opt/doka//pgsql/bin/createdb:
undefined symbol: get_proname
pg_regress: createdb failed
make[2]: *** [check] Fehler 2
make[2]: Leaving directory
`/usr/local/src/postgresql-7.4beta4/src/test/regress'
make[1]: *** [check] Fehler 2
make[1]: Leaving directory `/usr/local/src/postgresql-7.4beta4/src/test'
make: *** [check] Fehler 2
postgres(at)zs:/usr/local/src/postgresql-7.4beta4>

Regards
Christoph Becker

Christoph Becker <CGBecker(at)gmx(dot)de> writes:
> ============== creating database "regression" ==============
> /usr/local/src/postgresql-7.4beta4/src/test/regress/./tmp_check/install//opt/doka//pgsql/bin/createdb:
> relocation error:
> /us/local/src/postgresql-7.4beta4/src/test/regress/./tmp_check/install//opt/doka//pgsql/bin/createdb:
> undefined symbol: get_proname
> pg_regress: createdb failed

Hm. I have a feeling your temp installation is somehow linking to an
old version of libpq, because that's the most common reason for
link-time failures in "make check". But I don't understand the
reference to 'get_proname'. There is no occurrence of that string in
either current sources or any recent PG release.

regards, tom lane

tgl(at)sss(dot)pgh(dot)pa(dot)us wrote:
> Christoph Becker <CGBecker(at)gmx(dot)de> writes:
>> ============== creating database "regression" ==============
>> /usr/local/src/postgresql-7.4beta4/src/test/regress/./tmp_check/install//opt/doka//pgsql/bin/createdb:
>> relocation error:
>> /us/local/src/postgresql-7.4beta4/src/test/regress/./tmp_check/install//opt/doka//pgsql/bin/createdb:
>> undefined symbol: get_proname
>> pg_regress: createdb failed
>
> Hm. I have a feeling your temp installation is somehow linking to an
> old version of libpq, because that's the most common reason for
> link-time failures in "make check". But I don't understand the
> reference to 'get_proname'. There is no occurrence of that string in
> either current sources or any recent PG release.

I got the same error with beta1, but the symbol was "get_progname"
not "get_proname". Perhaps the above is a typo. I also thought the thing
was somehow using my current 7.3 install when linking the 7.4 tests.
Didn't happen with beta2, but could be because then I had beta1 installed.

ljb <ljb220(at)mindspring(dot)com> writes:
> I got the same error with beta1, but the symbol was "get_progname"
> not "get_proname". Perhaps the above is a typo.

"get_progname" would make sense, because that's a symbol defined in
libpgport in 7.4 that did not exist in 7.3. So if the dynamic linker
was finding your 7.3 PG library directory instead of 7.4, you'd likely
get this error.

regards, tom lane

tgl(at)sss(dot)pgh(dot)pa(dot)us wrote:
> ljb <ljb220(at)mindspring(dot)com> writes:
>> I got the same error with beta1, but the symbol was "get_progname"
>> not "get_proname". Perhaps the above is a typo.
>
> "get_progname" would make sense, because that's a symbol defined in
> libpgport in 7.4 that did not exist in 7.3. So if the dynamic linker
> was finding your 7.3 PG library directory instead of 7.4, you'd likely
> get this error.

Confirmed. Perhaps this should be looked into. On my system, "make check"
works fine if there is no existing PostgreSQL installation. But if there
is, we seem to prefer the existing installation's libraries over what
pg_regress sets LD_LIBRARY_PATH to (the newly built software). This means
that "make check" will either fail in createdb (if the existing install is
7.3, for example) or work but actually be testing the newly built programs
using the existing version's run-time libpq library.

ljb <ljb220(at)mindspring(dot)com> writes:
> Confirmed. Perhaps this should be looked into. On my system, "make check"
> works fine if there is no existing PostgreSQL installation. But if there
> is, we seem to prefer the existing installation's libraries over what
> pg_regress sets LD_LIBRARY_PATH to (the newly built software). This means
> that "make check" will either fail in createdb (if the existing install is
> 7.3, for example) or work but actually be testing the newly built programs
> using the existing version's run-time libpq library.

Yeah, we have seen this before on various platforms. On some,
LD_LIBRARY_PATH isn't actually anything the dynamic linker pays
attention to, and on others, it is trumped by the installation rpath
built into the executables. Not putting an rpath into the executables
would make life better for "make check" at the cost of making the
executables much more fragile in actual use. I don't see a good
solution :-( but if you do, step right up to the plate ...

regards, tom lane

tgl(at)sss(dot)pgh(dot)pa(dot)us wrote:
> Yeah, we have seen this before on various platforms. On some,
> LD_LIBRARY_PATH isn't actually anything the dynamic linker pays
> attention to, and on others, it is trumped by the installation rpath
> built into the executables. Not putting an rpath into the executables
> would make life better for "make check" at the cost of making the
> executables much more fragile in actual use. I don't see a good
> solution :-( but if you do, step right up to the plate ...

Well, I'm not going to be the one who suggests that adding:
export LD_PRELOAD=$libdir/libpq.so
to pg_regress.sh before the initdb command will fix it (on Linux).

Because the more I think about it, the less I like the idea of "make check"
as a way to validate PostgreSQL. Not only because it looks like some of us
may have actually been testing a hybrid "new programs/old libraries"
combination, but because "make check" uses a temporary installation. For
acceptance testing, I want to know that it was built and installed
properly, so I'll have to use "make installcheck" after installation. (Say,
why isn't this listed in INSTALL anymore?)

Next bug.
--with full russian version of Pgadmin 3.1 (with russian title of column
and russian inserted data) : there is problem when selecting, inserting
relatively large block of data (for example , excerpt of some text about
100 words size and more). Pgadmin suddenly ends to work and then I have
to start pgadmin again, but fortunately data don t loose. And pgadmin
don t export any russian data to *.csv or *.dat - pgadmin
suddenly ends to work without saving any data. As I understood, there
is patch that solve this problems, so I hope new version of pgadmin
will appear as soon as possible.
--with full english version of Pgadmin : this problems absent , but
there is one thing that I don t understand and don t like me. When
exporting relatively large block of data (text with, for example, 100
words size) pgadmin saves to *.csv only little part of data in the end
of which follows ".." . So pgadmin don t safe full content of row. Is
it right behavior? How can I safe full content of a row?
--when inserting large block of text , data often aligns along one long
line, so its hard to view such data. It would be better if data take the
form of sell like , for example, Pgaccess does.

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

Andreas Pflug wrote:

> Alexandr S wrote:
>
>> Pgadmin 3.1 don t work (operations like insert rows) with columns
>> named in russian language (title of column in russian language). But
>> the same operations using PhpPgAdmin - all works very well, right.
>> And if replace russian title of column with equivalent in english -
>> all works very well. PgAdmin responds the message: "2003-10-03
>> 14:15:15 ERROR : Column not found in pgSet: еще_колонка". Operation
>> System: Windows XP, distribution binary (zip), language russian.
>>
> Hi Alexandr,
>
> you're on the wrong list, please use pgadmin-support for pgAdmin
> related questions.
>
> Which tool did you use to insert the data?
>
> Regards,
> Andreas
>
>
>

Alexandr S wrote:

> Next bug.
> --with full russian version of Pgadmin 3.1 (with russian title of
> column and russian inserted data) : there is problem when selecting,
> inserting relatively large block of data (for example , excerpt of
> some text about 100 words size and more). Pgadmin suddenly ends to
> work and then I have to start pgadmin again, but fortunately data don
> t loose. And pgadmin don t export any russian data to *.csv or
> *.dat - pgadmin suddenly ends to work without saving any data. As I
> understood, there is patch that solve this problems, so I hope new
> version of pgadmin will appear as soon as possible.

Hi Alexandr,
There's no patch pending, how did you try to insert the data? Can you
supply samples of data, so we can see what's going wrong?

>
> --with full english version of Pgadmin : this problems absent , but
> there is one thing that I don t understand and don t like me. When
> exporting relatively large block of data (text with, for example, 100
> words size) pgadmin saves to *.csv only little part of data in the
> end of which follows ".." . So pgadmin don t safe full content of
> row. Is it right behavior? How can I safe full content of a row?

The column size of the Query Tool is limited, you can change the setting
in options. Anyhow, if the data is larger than 511, windows will
truncate it.
The next version of pgAdmin3 will include a "execute to file", which
won't suffer any truncation (until the disk is full :-)

>
> --when inserting large block of text , data often aligns along one
> long line, so its hard to view such data. It would be better if data
> take the form of sell like , for example, Pgaccess does.

Don't know how you'd like it. Some kind of autowrap? You could split lines:

INSERT INTO mytable(foo, bar) VALUES (1, 'this is my line ||
' and this too'

Regards,
Andreas

Hi Alexandr,

please do not post only to persons, but at least cc the list to avoid
messages being lost.

> Hi
> -----In console:
> CREATE DATABASE mydb WITH ENCODING = 'KOI8';
> CREATE TABLE mytable ( моя_колонка varchar ) WITH OIDS;
> Then I open pgadmin, open View Data and insert into mytable text_s
> (text_s is attached to this letter) - pgadmin suddenly shut down with
> error: "An error has occured: Column not found in pgSet : моя_колонка".

This was fixed some time ago in cvs.

> Then I have to open pgadmin again. Fortunately data didn t lose. Then
> I open Query Tool and type: "SELECT * from mytable;" . Result of
> the query is right. Then I try to export data but I cann t do that
> because pgadmin suddenly shut down without saving any data.
> text_s is attached to this letter.

What format is this? I can't display it with any tool correctly. Please
use Notepad and Save-As some Unicode format.

> ----When will approximately new version with "execute to file"
> appear? (in a month , in a year ...)

It's already in cvs, binary coming soon.

>
>>> --when inserting large block of text , data often aligns along one
>>> long line, so its hard to view such data. It would be better if data
>>> take the form of sell like , for example, Pgaccess does.
>>
>>
>>
>>
>> Don't know how you'd like it. Some kind of autowrap? You could split
>> lines:
>>
>> INSERT INTO mytable(foo, bar) VALUES (1, 'this is my line ||
>> ' and this too'
>>
>>
>> Regards,
>> Andreas
>>
> ---Yes, some kind of autowrap. Of course I can mannually split line ,
> but users here usually do such way: ctrl-c from MS Word and ctrl-v
> into pgadmin, so data often align along one long line.

?????? Inserting data from Word ?????
pgAdmin3 is no text editing tool, and we won't try to interpret the
data. I don't know how you're trying to use pgAdmin3, but it may be out
of the scope of this tool (notice the name, it's about ADMINistration,
not for extensively editing data).

Regards,
Andreas

Andreas Pflug wrote:

> Then I have to open pgadmin again. Fortunately data didn t lose. Then
> I open Query Tool and type: "SELECT * from mytable;" . Result of
> the query is right. Then I try to export data but I cann t do that
> because pgadmin suddenly shut down without saving any data.
>
>> text_s is attached to this letter.
>
>
> What format is this? I can't display it with any tool correctly.
> Please use Notepad and Save-As some Unicode format.
>
Hi
----It can be usually opened with Opera or Mozilla Firebird having set
before Character Coding to windows-1251. May be fonts don t support
russian language. Any way with text_s_unicode in unicode there is the
same problem: I can t export such data from Query Window ( Pgadmin 3.1)
to file.

>
>
>>
>>>> --when inserting large block of text , data often aligns along one
>>>> long line, so its hard to view such data. It would be better if
>>>> data take the form of sell like , for example, Pgaccess does.
>>>
>>>
>>>
>>>
>>>
>>> Don't know how you'd like it. Some kind of autowrap? You could split
>>> lines:
>>>
>>> INSERT INTO mytable(foo, bar) VALUES (1, 'this is my line ||
>>> ' and this too'
>>>
>>>
>>> Regards,
>>> Andreas
>>>
>> ---Yes, some kind of autowrap. Of course I can mannually split line
>> , but users here usually do such way: ctrl-c from MS Word and ctrl-v
>> into pgadmin, so data often align along one long line.
>
>
> ?????? Inserting data from Word ?????
> pgAdmin3 is no text editing tool, and we won't try to interpret the
> data. I don't know how you're trying to use pgAdmin3, but it may be
> out of the scope of this tool (notice the name, it's about
> ADMINistration, not for extensively editing data).
>
----Why not? Let it be. What another tool should I use to insert data to
postgresql? Pgadmin already can be excellently used for such operations.
Not editing , but just coping from notepad to Pgadmin. Else I have to
create my own program using PHP , etc ...

Andreas Pflug wrote:

> Alexandr S wrote:
>
>> ----It can be usually opened with Opera or Mozilla Firebird having
>> set before Character Coding to windows-1251. May be fonts don t
>> support russian language. Any way with text_s_unicode in unicode
>> there is the same problem: I can t export such data from Query Window
>> ( Pgadmin 3.1) to file.
>
>
> Alexandr,
> please send this data as Unicode to me, if you want me to have a look
> at the problem. I can't set my win32 machine to windows-1251.
>
text_s_unicode was attached to last letter (file text_s_unicode.txt). I
attach this file to this letter again, so look for Attachments in this
letter.

Alexandr S wrote:

> ----It can be usually opened with Opera or Mozilla Firebird having set
> before Character Coding to windows-1251. May be fonts don t support
> russian language. Any way with text_s_unicode in unicode there is
> the same problem: I can t export such data from Query Window ( Pgadmin
> 3.1) to file.

Alexandr,
please send this data as Unicode to me, if you want me to have a look at
the problem. I can't set my win32 machine to windows-1251.

>>
> ----Why not? Let it be. What another tool should I use to insert data
> to postgresql? Pgadmin already can be excellently used for such
> operations. Not editing , but just coping from notepad to Pgadmin.
> Else I have to create my own program using PHP , etc ...

Sure you can copy/paste the data, but don't expect it to be formatted in
any way. There are intentions to create an additional tool with extended
data handling capabilities, but that are just plans so far.

Regards,
Andreas

Alexandr S wrote:

> Andreas Pflug wrote:
>
>> Alexandr S wrote:
>>
>>> ----It can be usually opened with Opera or Mozilla Firebird having
>>> set before Character Coding to windows-1251. May be fonts don t
>>> support russian language. Any way with text_s_unicode in unicode
>>> there is the same problem: I can t export such data from Query
>>> Window ( Pgadmin 3.1) to file.
>>
>>
>>
>> Alexandr,
>> please send this data as Unicode to me, if you want me to have a look
>> at the problem. I can't set my win32 machine to windows-1251.
>>
> text_s_unicode was attached to last letter (file text_s_unicode.txt).
> I attach this file to this letter again, so look for Attachments in
> this letter.
>
>
>
Hi Alexandr,
this second file version was readable for me.

I created database and table with your script, opened ViewData on the
table, copied your text_s from Notepad into the column, and stored it.

View Data shows the contents fine, Query Tool does so too with select *
from mytable. When exporting from query tool, data is truncated (which
is normal), the new "execute to file" will export all.

So I can't reproduce this problem.

In the next days (when Dave gets the time to do so) we'll have V1.0.2
out, which fixes that "column not found" problem, and should work for
you. Execute to file isn't included there, we will have snapshots of the
forthcoming V1.1 for that.

Regards,
Andreas

>------------------------------------------------------------------------
>
>яю !!/-
>
>------------------------------------------------------------------------
>
>
>---------------------------(end of broadcast)---------------------------
>TIP 9: the planner will ignore your desire to choose an index scan if your
> joining column's datatypes do not match
>
>