gibt es eine aktuelle pgTcl-lib für Windows?

Hi zusammen,

ein Freund entwickelt seit Jahren eine Open-Source-Fibu für PostgreSQL.
(M.W. die einzige, die es gibt - http://tkfibu.de/)

Sie läuft unter Linux mit PgTcl - leider gibt es aber pgTcl nicht für
aktuelle win-Versionen. (Nicht dass ich das selbst nun wirklich vermisse)
Aber ich finde es schade, dass ein so ambitioniertes Projekt - das ja
aufgrund von Tcl/Tk grundsätzlich OS-unabhängig ist - nicht unter
Win benutzbar ist.
Etwas Hoffnung keimte auf als ich sah, dass https://github.com/flightaware/Pgtcl
offenbar doch noch supported wird (Jul 14, 2022) - aber für win gibt
es nur ein w32-makefile und bei Sourceforge heisst es ebenfalls (2017):

There is currently no support for building with 64-bit components or systems.

Hab ich irgendwas übersehen? Gibt es doch eine pgTcl-lib für w64 oder kann
man das definitiv vergessen?
Ich fürchte, wg. der abnehmenden Verbreitung von Tcl wird ein solches
Projekt niemand mehr anfassen wollen.
Oder hat hier jemand mehr Infos dazu?

Viele Grüße

Ralf

Hallo Ralf,

lässt sich der Quelltext nicht übersetzen? Es muss ja keine fertige Lib geben.

Ich bin kein Windows-Anwender, aber grundsätzlich sollte das möglich sein, ob 32 oder 64 bit.

Gruß
Holger

Am 29. Juli 2022 07:33:22 MESZ schrieb Ralf Burger <ralf(at)Burger-AG(dot)de>:
>Hi zusammen,
>
>ein Freund entwickelt seit Jahren eine Open-Source-Fibu für PostgreSQL.
>(M.W. die einzige, die es gibt - http://tkfibu.de/)
>
>Sie läuft unter Linux mit PgTcl - leider gibt es aber pgTcl nicht für
>aktuelle win-Versionen. (Nicht dass ich das selbst nun wirklich vermisse)
>Aber ich finde es schade, dass ein so ambitioniertes Projekt - das ja
>aufgrund von Tcl/Tk grundsätzlich OS-unabhängig ist - nicht unter
>Win benutzbar ist.
>Etwas Hoffnung keimte auf als ich sah, dass https://github.com/flightaware/Pgtcl
>offenbar doch noch supported wird (Jul 14, 2022) - aber für win gibt
>es nur ein w32-makefile und bei Sourceforge heisst es ebenfalls (2017):
>
>There is currently no support for building with 64-bit components or systems.
>
>Hab ich irgendwas übersehen? Gibt es doch eine pgTcl-lib für w64 oder kann
>man das definitiv vergessen?
>Ich fürchte, wg. der abnehmenden Verbreitung von Tcl wird ein solches
>Projekt niemand mehr anfassen wollen.
>Oder hat hier jemand mehr Infos dazu?
>
>Viele Grüße
>
>Ralf
>
>
>
>

Hi Holger,

Am 29.07.22 um 09:26 schrieb Holger Jakobs:
> lässt sich der Quelltext nicht übersetzen? Es muss ja keine fertige Lib geben.
> Ich bin kein Windows-Anwender, aber grundsätzlich sollte das möglich sein, ob 32 oder 64 bit.

naja, die schreiben sicherlich nicht umsonst dazu, dass es nicht möglich ist
es mit 64-Bit ;-)

Anfang des Jahres hatte ich es mal mit 64-Bit versucht dann aber aufgeben.
Denn damals waren die letzten Aktualisierungen, die ich gefunden hatte aus 2013.

Ich werde aber mal versuchen, es auf einer 32-bit-Version zu übersetzen.

Aber auch da bin ich noch skeptisch - denn es gab (wenn ich mich recht erinnere)
sehr viele Abhängigkeiten.

Ob es klappt oder nicht werde ich dann mal posten.

Viele Grüße

Ralf

Hi zusammen,

hier die Rückmeldung:

pgtcl habe ich verworfen - da ich es weder unter w64 noch unter
w32 compiliert bekommen habe.

Aber mit dem hier

https://sourceforge.net/projects/pgintcl/

kann man via Tcl auf Postgres zugreifen und mit
marginalen Änderungen bekommt man Tkfibu unter Win gestartet.

Der Autor versucht jetzt das komplett zu integrieren.
Die Lösung finde ich deutlich besser als auf eine zusätzliche
binary-Lib zugreifen zu müssen.

Viele Grüße

Ralf

> Am 29.07.22 ...
> Aber auch da bin ich noch skeptisch - denn es gab (wenn ich mich recht erinnere)
> sehr viele Abhängigkeiten.
>
> Ob es klappt oder nicht werde ich dann mal posten.

Hallo Ralf,

geht, aber es unterstützt leider nicht das neue Kennwortverfahren SCRAM,
sondern nur das alte MD5.

Von daher ist davon eher abzuraten. Außerdem ist es viel langsamer.

Gruß

Holger

Am 08.08.22 um 15:43 schrieb Ralf Burger:
> Hi zusammen,
>
> hier die Rückmeldung:
>
> pgtcl habe ich verworfen - da ich es weder unter w64 noch unter
> w32 compiliert bekommen habe.
>
> Aber mit dem hier
>
>  https://sourceforge.net/projects/pgintcl/
>
> kann man via Tcl auf Postgres zugreifen und mit
> marginalen Änderungen bekommt man Tkfibu unter Win gestartet.
>
> Der Autor versucht jetzt das komplett zu integrieren.
> Die Lösung finde ich deutlich besser als auf eine zusätzliche
> binary-Lib zugreifen zu müssen.
>
>
> Viele Grüße
>
> Ralf
>
>
>> Am 29.07.22 ...
>> Aber auch da bin ich noch skeptisch - denn es gab (wenn ich mich
>> recht erinnere)
>> sehr viele Abhängigkeiten.
>>
>> Ob es klappt oder nicht werde ich dann mal posten.
>
>
--
Holger Jakobs, Bergisch Gladbach, Tel. +49-178-9759012

Hallo zusammen,
also compilieren unter Windows geht mit msys2.

meine Voraussetzungen:
- windows 11 21H2 64bit
- msys2 mit etlichen Packages, u.A. gcc, make, tcl usw.
  k.A. welche Abhängigkeiten eine Neuinstallation abdeckt, aber pacman
hilft gerne nach.
- postgresql 14.4 (x86-64) installiert
- postgresql source 14.4
- flightaware/pgtcl source release 3.0.0 (trotzdem 2.7.7 drin)

Vorbereitung:
postgresql source ./configure generiert passende header, KEIN make!

Pgtcl selbst:
autoreconf
./configure + fehlende include-Pfade und explizit ws2_32(ohne ging's
nicht) per CFLAGS/LIBS beigemischt
make spuckt dann die passende Pgtcl277.dll aus.

Test:
Beispiel aus der Pgtcl-Doku(DB-Namen auflisten) lief als Script einwandfrei.
wurde per Tclsh.exe(mingw64-binary) ausgeführt, auch mit
windows-terminal aufrufbar.
nur "package require " wollte nicht, ging mit "load " einzubinden.

das war's dann auch schon.

es ist nicht unmöglich, aber die Frage bleibt ob man so eine
passende(wirklich 64bit und kein Wrapper oder irgendein
Pseudo-64Bit-Flipper) Implementation hat oder nicht.

Gruß

Alex

Am 08.08.2022 um 15:48 schrieb Holger Jakobs:
> Hallo Ralf,
>
> geht, aber es unterstützt leider nicht das neue Kennwortverfahren
> SCRAM, sondern nur das alte MD5.
>
> Von daher ist davon eher abzuraten. Außerdem ist es viel langsamer.
>
> Gruß
>
> Holger
>
> Am 08.08.22 um 15:43 schrieb Ralf Burger:
>> Hi zusammen,
>>
>> hier die Rückmeldung:
>>
>> pgtcl habe ich verworfen - da ich es weder unter w64 noch unter
>> w32 compiliert bekommen habe.
>>
>> Aber mit dem hier
>>
>>  https://sourceforge.net/projects/pgintcl/
>>
>> kann man via Tcl auf Postgres zugreifen und mit
>> marginalen Änderungen bekommt man Tkfibu unter Win gestartet.
>>
>> Der Autor versucht jetzt das komplett zu integrieren.
>> Die Lösung finde ich deutlich besser als auf eine zusätzliche
>> binary-Lib zugreifen zu müssen.
>>
>>
>> Viele Grüße
>>
>> Ralf
>>
>>
>>> Am 29.07.22 ...
>>> Aber auch da bin ich noch skeptisch - denn es gab (wenn ich mich
>>> recht erinnere)
>>> sehr viele Abhängigkeiten.
>>>
>>> Ob es klappt oder nicht werde ich dann mal posten.
>>
>>

Hi Alex,

vielen Dank! Das ist schon mal ein guter Hinweis.

Wir testen aber gerade noch mit pgin.tcl herum und
nun stellt sich raus:

Damit kommt kein DB-connect zustande.
Nicht mit PG 14.
(mit 9 und 12 ging es)

Auch tkpsql.tcl meldet beim Verbindungsversuch:

Unknown database authentication request(10)

Im tcpdump sehe ich:

.x.T.x.RR.......SCRAM-SHA-256.....

obwohl SCRAM in den Configs überall abgeschaltet und MD5
eingeschaltet ist - und pgin kann überhaupt kein SCRAM.
Offenbar verlangt/erwartet PG 14 SCRAM-SHA-256.

und das PG-log ist (selbst auf "debug5") nicht wirklich
hilfreich:

2022-08-26 17:10:19.077 CEST [559269] [unknown](at)[unknown] LOG: 00000: connection received: host=localhost port=38849
2022-08-26 17:10:19.077 CEST [559269] [unknown](at)[unknown] LOCATION: BackendInitialize, postmaster.c:4413

Hat sonst jemand vielleicht spontan eine Idee dazu?

Viele Grüße

Ralf

Am 18.08.22 um 02:26 schrieb postgresql439848(at)heinz-it(dot)de:
> Hallo zusammen,
> also compilieren unter Windows geht mit msys2.
>
> meine Voraussetzungen:
> - windows 11 21H2 64bit
> - msys2 mit etlichen Packages, u.A. gcc, make, tcl usw.
>   k.A. welche Abhängigkeiten eine Neuinstallation abdeckt, aber pacman hilft gerne nach.
> - postgresql 14.4 (x86-64) installiert
> - postgresql source 14.4
> - flightaware/pgtcl source release 3.0.0 (trotzdem 2.7.7 drin)
>
> Vorbereitung:
> postgresql source ./configure generiert passende header, KEIN make!
>
> Pgtcl selbst:
> autoreconf
> ./configure + fehlende include-Pfade und explizit ws2_32(ohne ging's nicht) per CFLAGS/LIBS beigemischt
> make spuckt dann die passende Pgtcl277.dll aus.
>
> Test:
> Beispiel aus der Pgtcl-Doku(DB-Namen auflisten) lief als Script einwandfrei.
> wurde per Tclsh.exe(mingw64-binary) ausgeführt, auch mit windows-terminal aufrufbar.
> nur "package require " wollte nicht, ging mit "load " einzubinden.
>
> das war's dann auch schon.
>
>
> es ist nicht unmöglich, aber die Frage bleibt ob man so eine passende(wirklich 64bit und kein Wrapper oder irgendein Pseudo-64Bit-Flipper) Implementation hat
> oder nicht.
>
> Gruß
>
> Alex
>
>
> Am 08.08.2022 um 15:48 schrieb Holger Jakobs:
>> Hallo Ralf,
>>
>> geht, aber es unterstützt leider nicht das neue Kennwortverfahren SCRAM, sondern nur das alte MD5.
>>
>> Von daher ist davon eher abzuraten. Außerdem ist es viel langsamer.
>>
>> Gruß
>>
>> Holger
>>
>> Am 08.08.22 um 15:43 schrieb Ralf Burger:
>>> Hi zusammen,
>>>
>>> hier die Rückmeldung:
>>>
>>> pgtcl habe ich verworfen - da ich es weder unter w64 noch unter
>>> w32 compiliert bekommen habe.
>>>
>>> Aber mit dem hier
>>>
>>>  https://sourceforge.net/projects/pgintcl/
>>>
>>> kann man via Tcl auf Postgres zugreifen und mit
>>> marginalen Änderungen bekommt man Tkfibu unter Win gestartet.
>>>
>>> Der Autor versucht jetzt das komplett zu integrieren.
>>> Die Lösung finde ich deutlich besser als auf eine zusätzliche
>>> binary-Lib zugreifen zu müssen.
>>>
>>>
>>> Viele Grüße
>>>
>>> Ralf
>>>
>>>
>>>> Am 29.07.22 ...
>>>> Aber auch da bin ich noch skeptisch - denn es gab (wenn ich mich recht erinnere)
>>>> sehr viele Abhängigkeiten.
>>>>
>>>> Ob es klappt oder nicht werde ich dann mal posten.
>>>
>>>
>
>

--
Mit freundlichen Gruessen

Ralf Burger
-----------------------------------------------------------------
Ralf Burger AG
Roenskenstr. 37
46562 Voerde

HRB: AG Duisburg HRB 18758
USt.-ID: DE151403601
Vorstand: Heidrun Besier
Vorsitzender des Aufsichtsrates: Ralf Burger

Telefon und Internet
====================
Festnetz: 02855 / 26 18
0700 123 456 00 (12ct/min)

Internet: http://www.burger-ag.de/
PGP-public-Key:
http://erste.de/ralf(at)Burger-AG(dot)de(dot)PGP_0x87011269177D751F(dot)pub(dot)asc

Hi Ralf,

ja, pgin.tcl kann kein SCRAM, das hatte ich ja früher schon geschrieben.

Wenn alles richtig eingestellt ist, gelingt auch mit PG 14.5 ein Login
mit MD5-Kennwort.

Voraussetzungen:

1. Rolle muss eingerichtet werden, während password_encryption = md5
aktiv ist.
2. Für die Rolle muss eine passende Zeile in pg_hba.conf eingerichtet
sein (vor allgemeineren Zeilen, denn der erste Treffer zählt).
3. Verbindung muss hergestellt werden, während password_encryption =
md5 aktiv ist.

Habe es gerade noch einmal mit Version 3.5.1 von pgin.tcl probiert.

Viele Grüße

Holger

Am 26.08.22 um 17:19 schrieb Ralf Burger:
> Hi Alex,
>
> vielen Dank! Das ist schon mal ein guter Hinweis.
>
> Wir testen aber gerade noch mit pgin.tcl herum und
> nun stellt sich raus:
>
> Damit kommt kein DB-connect zustande.
> Nicht mit PG 14.
> (mit 9 und 12 ging es)
>
> Auch tkpsql.tcl meldet beim Verbindungsversuch:
>
> Unknown database authentication request(10)
>
> Im tcpdump sehe ich:
>
> .x.T.x.RR.......SCRAM-SHA-256.....
>
>
> obwohl SCRAM in den Configs überall abgeschaltet und MD5
> eingeschaltet ist - und pgin kann überhaupt kein SCRAM.
> Offenbar verlangt/erwartet PG 14 SCRAM-SHA-256.
>
> und das PG-log ist (selbst auf "debug5") nicht wirklich
> hilfreich:
>
> 2022-08-26 17:10:19.077 CEST [559269] [unknown](at)[unknown] LOG: 00000:
> connection received: host=localhost port=38849
> 2022-08-26 17:10:19.077 CEST [559269] [unknown](at)[unknown] LOCATION: 
> BackendInitialize, postmaster.c:4413
>
> Hat sonst jemand vielleicht spontan eine Idee dazu?
>
>
> Viele Grüße
>
> Ralf
>
>
>
>
>
>
> Am 18.08.22 um 02:26 schrieb postgresql439848(at)heinz-it(dot)de:
>> Hallo zusammen,
>> also compilieren unter Windows geht mit msys2.
>>
>> meine Voraussetzungen:
>> - windows 11 21H2 64bit
>> - msys2 mit etlichen Packages, u.A. gcc, make, tcl usw.
>>    k.A. welche Abhängigkeiten eine Neuinstallation abdeckt, aber
>> pacman hilft gerne nach.
>> - postgresql 14.4 (x86-64) installiert
>> - postgresql source 14.4
>> - flightaware/pgtcl source release 3.0.0 (trotzdem 2.7.7 drin)
>>
>> Vorbereitung:
>> postgresql source ./configure generiert passende header, KEIN make!
>>
>> Pgtcl selbst:
>> autoreconf
>> ./configure + fehlende include-Pfade und explizit ws2_32(ohne ging's
>> nicht) per CFLAGS/LIBS beigemischt
>> make spuckt dann die passende Pgtcl277.dll aus.
>>
>> Test:
>> Beispiel aus der Pgtcl-Doku(DB-Namen auflisten) lief als Script
>> einwandfrei.
>> wurde per Tclsh.exe(mingw64-binary) ausgeführt, auch mit
>> windows-terminal aufrufbar.
>> nur "package require " wollte nicht, ging mit "load " einzubinden.
>>
>> das war's dann auch schon.
>>
>>
>> es ist nicht unmöglich, aber die Frage bleibt ob man so eine
>> passende(wirklich 64bit und kein Wrapper oder irgendein
>> Pseudo-64Bit-Flipper) Implementation hat oder nicht.
>>
>> Gruß
>>
>> Alex
>>
>>
>> Am 08.08.2022 um 15:48 schrieb Holger Jakobs:
>>> Hallo Ralf,
>>>
>>> geht, aber es unterstützt leider nicht das neue Kennwortverfahren
>>> SCRAM, sondern nur das alte MD5.
>>>
>>> Von daher ist davon eher abzuraten. Außerdem ist es viel langsamer.
>>>
>>> Gruß
>>>
>>> Holger
>>>
>>> Am 08.08.22 um 15:43 schrieb Ralf Burger:
>>>> Hi zusammen,
>>>>
>>>> hier die Rückmeldung:
>>>>
>>>> pgtcl habe ich verworfen - da ich es weder unter w64 noch unter
>>>> w32 compiliert bekommen habe.
>>>>
>>>> Aber mit dem hier
>>>>
>>>> https://sourceforge.net/projects/pgintcl/
>>>>
>>>> kann man via Tcl auf Postgres zugreifen und mit
>>>> marginalen Änderungen bekommt man Tkfibu unter Win gestartet.
>>>>
>>>> Der Autor versucht jetzt das komplett zu integrieren.
>>>> Die Lösung finde ich deutlich besser als auf eine zusätzliche
>>>> binary-Lib zugreifen zu müssen.
>>>>
>>>>
>>>> Viele Grüße
>>>>
>>>> Ralf
>>>>
>>>>
>>>>> Am 29.07.22 ...
>>>>> Aber auch da bin ich noch skeptisch - denn es gab (wenn ich mich
>>>>> recht erinnere)
>>>>> sehr viele Abhängigkeiten.
>>>>>
>>>>> Ob es klappt oder nicht werde ich dann mal posten.
>>>>
>>>>
>>
>>
>
--
Holger Jakobs, Bergisch Gladbach, Tel. +49-178-9759012

Hi Holger,

Am 26.08.22 um 18:34 schrieb Holger Jakobs:
> 1. Rolle muss eingerichtet werden, während password_encryption = md5
^^^^^^^
>    aktiv ist.

jau - das war es. Danke! ;-)

Da muss man erst mal drauf kommen, dass es auf die Config der
Encryption beim Einrichten des Users ankommt.

wird aber schnell klar, wenn man in
SELECT rolpassword FROM pg_authid;
reinschaut.....

mal so
SCRAM-SHA-256$4096:cvcLQwbD/bhj.....
und mal so
md5078bbb4bf0f7117fb131ec45f15b.....

Man müsste in pgin vielleicht eine passende Fehlermeldung einbauen.
mal schauen.

gruss

ralf

Hi nochmal,

also so langsam werd ich porös...

Neues Problem:

Nun kann ich unter Linux via pgin connecten - versuche ich das gleiche
unter Win, dann erhalte ich mit "wish tkpsql.tcl":

Failed to connect to Database: unknown encoding 'identity'

Das kommt wohl direkt aus dem pgin.tcl.
Auch bei einem PG 12.11-Server.

Da ich aber sicher bin, dass das schon mal lief, habe ich alte
pgin-Versionen heruntergeladen: Nur die Version 2.2.1 funktioniert.

Ab Version 3 kommt die obige Meldung.
Aber nur unter Win - Unter Linux geht es.
Und auch nur bei der Win64-Version, die ich gerade teste.
Und bei Win ist es egal, ob ich es über Cygwin oder über den Command
starte.
Mit pgin 2.2.1 kann ich sowohl tkpsql als auch die tkfibu starten und
es funktioniert.

Ich weiss aber, dass es auf anderen Win-Versionen läuft.
(da weiss ich aber nicht, welche pgin-Version verwendet wird. erfrage ich noch)
Aber was ist der Unterschied? Irgendeine Env-Variable oder sowas?

Die Meldung klingt ja so, als ob er einen Encoding-Parameter erwartet
und der fehlt.

TCL kenne ich zu wenig um aus den Login-Abläufen schnell
schlau zu werden.

Jemand auf Anhieb eine Idee dazu?

Gruss

ralf

Hallo Ralf,

das Wort identity müsste im Code vorkommen, wenn es als Name eines Encodings übermittelt wird.

PostgreSQL kennt kein Encoding dieses Namens. Tcl kann prima mit UTF8 arbeiten, PostgreSQL arbeitet sowieso damit.

Windows arbeitet sonst viel mit cp1252 (GUI) und cp850 (Eingabeaufforderung). Weiterhelfen kann ich bei Windows ansonsten nicht, weil ich es nicht verwende.

Viele Grüße
Holger

Am 27. August 2022 05:06:06 MESZ schrieb Ralf Burger <ralf(at)Burger-AG(dot)de>:
>Hi nochmal,
>
>also so langsam werd ich porös...
>
>Neues Problem:
>
>Nun kann ich unter Linux via pgin connecten - versuche ich das gleiche
>unter Win, dann erhalte ich mit "wish tkpsql.tcl":
>
>Failed to connect to Database: unknown encoding 'identity'
>
>
>Das kommt wohl direkt aus dem pgin.tcl.
>Auch bei einem PG 12.11-Server.
>
>Da ich aber sicher bin, dass das schon mal lief, habe ich alte
>pgin-Versionen heruntergeladen: Nur die Version 2.2.1 funktioniert.
>
>Ab Version 3 kommt die obige Meldung.
>Aber nur unter Win - Unter Linux geht es.
>Und auch nur bei der Win64-Version, die ich gerade teste.
>Und bei Win ist es egal, ob ich es über Cygwin oder über den Command
>starte.
>Mit pgin 2.2.1 kann ich sowohl tkpsql als auch die tkfibu starten und
>es funktioniert.
>
>Ich weiss aber, dass es auf anderen Win-Versionen läuft.
>(da weiss ich aber nicht, welche pgin-Version verwendet wird. erfrage ich noch)
>Aber was ist der Unterschied? Irgendeine Env-Variable oder sowas?
>
>Die Meldung klingt ja so, als ob er einen Encoding-Parameter erwartet
>und der fehlt.
>
>TCL kenne ich zu wenig um aus den Login-Abläufen schnell
>schlau zu werden.
>
>Jemand auf Anhieb eine Idee dazu?
>
>Gruss
>
>ralf
>
>

Hi Holger,

Am 27.08.22 um 17:32 schrieb Holger Jakobs:

> das Wort identity müsste im Code vorkommen, wenn es als Name eines Encodings übermittelt wird.

klar hab ich das alles schon mal durchgegreppt.
Und auch verdächtige Stellen gefunden. Aber ich bin
viel zu wenig TCL-Entwickler um das auf Anhieb einordnen
zu können.

> PostgreSQL kennt kein Encoding dieses Namens.

daher vermute ich ja, dass irgendwie ein Parameter oder
eine Env-Variable fehlt. Irgendein syntaktisches Problem
wird das sein.
Vermutlich ein saublödes "Wald vor lauter nicht seh"-Problem.

> Tcl kann prima mit UTF8 arbeiten, PostgreSQL arbeitet sowieso damit.
> Windows arbeitet sonst viel mit cp1252 (GUI) und cp850 (Eingabeaufforderung).
> Weiterhelfen kann ich bei Windows ansonsten nicht,

hast Du doch schon mit Deiner Mail von gestern.;-)

> weil ich es nicht verwende.

wir auch nicht....
Aber wenn man schon eine DB und eine Fibu hat, die darauf
laufen können sollten, dann wäre es ja schön, wenn sie es
auch tun.
Eine OS-PG-Linux-Fibu, die auch unter Win läuft, wär schon
cool.
Aber es ist ein "nice to have"-Feature - mehr nicht.

Viele Grüße

Ralf

Schick mir doch einfach mal deine Version von pgin.tcl

Am 27. August 2022 17:57:59 MESZ schrieb Ralf Burger <ralf(at)Burger-AG(dot)de>:
>Hi Holger,
>
>
>Am 27.08.22 um 17:32 schrieb Holger Jakobs:
>
>> das Wort identity müsste im Code vorkommen, wenn es als Name eines Encodings übermittelt wird.
>
>klar hab ich das alles schon mal durchgegreppt.
>Und auch verdächtige Stellen gefunden. Aber ich bin
>viel zu wenig TCL-Entwickler um das auf Anhieb einordnen
>zu können.
>
>
>> PostgreSQL kennt kein Encoding dieses Namens.
>
>daher vermute ich ja, dass irgendwie ein Parameter oder
>eine Env-Variable fehlt. Irgendein syntaktisches Problem
>wird das sein.
>Vermutlich ein saublödes "Wald vor lauter nicht seh"-Problem.
>
>
>> Tcl kann prima mit UTF8 arbeiten, PostgreSQL arbeitet sowieso damit.
>> Windows arbeitet sonst viel mit cp1252 (GUI) und cp850 (Eingabeaufforderung). Weiterhelfen kann ich bei Windows ansonsten nicht,
>
>hast Du doch schon mit Deiner Mail von gestern.;-)
>
>
>> weil ich es nicht verwende.
>
>wir auch nicht....
>Aber wenn man schon eine DB und eine Fibu hat, die darauf
>laufen können sollten, dann wäre es ja schön, wenn sie es
>auch tun.
>Eine OS-PG-Linux-Fibu, die auch unter Win läuft, wär schon
>cool.
>Aber es ist ein "nice to have"-Feature - mehr nicht.
>
>
>Viele Grüße
>
>Ralf
>
>
>
>
>
>
>