Since DictRow's can be indexed by either the field name or the field index
(either record["ID"] or record[0]) then I think what it "should" be is a little
ambiguous. But you can always either cast it to a dict, or iterate over .keys()
if you want the field names.
for field in dict(the_dict):
From https://www.psycopg.org/docs/sql.html
"The module contains objects and functions useful to generate SQL dynamically,
in a convenient and safe way."
If there's nothing dynamic about the text of the query, then you don't really
need to go through all the trouble of using all those classes. T
I just install Python 3.11, and am trying to install psycopg2 with pip and am
getting errors.
Seems to install just fine when I go back to 3.10, but 3.11 is giving me errors.
Seems to be the same error whether I'm trying to install psycopg2 or
psycopg2-binary.
This is on Windows. Below is the c
It appears that the .read_only attribute of a connection is not honored when
the connection is in autocommit mode.
There's no mention of this on the Connection classes page for read_only, and in
the section linked to in Transactions management you have to read it 3 times to
realize it's only us
I've noticed that CPU usage for queries seems to have drastically increased
going from psycopg2 to psycopg3.
In psycopg2 a connection would sit quietly while waiting for the results, using
next to no CPU.
In psycopg it looks like the threads are using their core at full power,
continuously chec
> Could you please be so kind as to repeat your tests with psycopg 3.1.4?
Tried with 3.1.4 and it has idle processor usage while waiting for the 8
results, just like psycopg2.
Tried with 3.1.5 and it spikes up to 62% reported CPU usage while waiting for
the 8 results, just like the current releas
Looks good. With the change it quietly idles while waiting for query results,
with no CPU spike.
-David
> Hello David,
>
> On Thu, 7 Sept 2023 at 14:17, David Raymond wrote:
>>
>> > Could you please be so kind as to repeat your tests with psycopg 3.1.4?
>> Tr
SELECT * FROM tbl;
returns a totally different table than
SELECT * FROM "tbl";
That's a little disconcerting.
For the capitalization thing basically what's going on is two things. (The way
I understand it)
1) Postgres IS case sensitive.
2) When any query gets sent to the server, the server conve
Could you let us know what version the server is, and also show a table
listing? (Connect with psql and do a \d for example)
From: Daniel Cohen
Sent: Thursday, June 13, 2019 4:55 PM
To: Christophe Pettus
Cc: psyc...@postgresql.org
Subject: Re: Creating dynamically-typed tables using psycopg2'
“Another workaround would be creation a row type for the desired set of columns
and casting %s to this type[], but I would not like to create additional
objects in the database because it is pretty much out of my control.”
Isn’t every table its own type? So could you do this?
inert into t
select
10 matches
Mail list logo
