Am Thu, Feb 15, 2024 at 11:45:15PM -0600 schrieb Karl O. Pinc:
> Today there is no substitute for knowing the encoding of the
> text your application obtains from the outside world.
> This can be highly system dependent because when reading
> files open()-ed as text, Python decodes (into UTF-8)
On Wed, 14 Feb 2024 19:28:57 +0100
Daniele Varrazzo wrote:
> On Wed, 14 Feb 2024 at 16:42, Karl O. Pinc wrote:
>
> > I did not use conn.info.encoding because the docs say that it
> > contains the _client_ encoding, not the server-side encoding
> > used to store the db content.
> > [...]
> > Con
Hello,
On Wed, 14 Feb 2024 at 16:42, Karl O. Pinc wrote:
> I did not use conn.info.encoding because the docs say that it
> contains the _client_ encoding, not the server-side encoding
> used to store the db content.
> [...]
> Confirming the encodings, connecting to the "latin1" db with psql sho
Hi Daniele,
On Wed, 14 Feb 2024 15:30:33 +0100
Daniele Varrazzo wrote:
> Note however that if you just want to know the Python codec you can
> find it in `conn.info.encoding`
> (https://www.psycopg.org/psycopg3/docs/api/objects.html#psycopg.ConnectionInfo.encoding):
>
> >>> conn.info.encodi
Hello Karl,
On Wed, 14 Feb 2024 at 02:37, Karl O. Pinc wrote:
> This does not work. What is wrong with what I'm doing
> and how do I do what I want? (And how am I supposed to
> know why this does not work and what works?) I call the
> dumper because I want to rely on psycopg3's mechanisms
> a
Hi,
I'm writing a program which takes a text file from the user,
constructs an INPUT statement (the table and column names are not
known in advance), and uses the constructed statement
to insert rows of the text file into PG.
psycopg3 v3.1.18 (installed in a venv)
PG v15.5
Python 3.11.2
Debian 12
