Re: After upgrading libpq, the same function(PQftype) call returns a different OID

2025-03-18 Thread Sebastien Flaesch
You are right Adrian, I did not search properly I found the header file here: sf@toro:/opt3/dbs/pgs/17.4$ ls -l include/postgresql/server/catalog/pg_type_d.h -rw-r--r-- 1 sf sf 9672 Mar 13 17:05 include/postgresql/server/catalog/pg_type_d.h I was not expecting this file to be in a "server" folde

pgvector as standard PostgreSQL feature?

2025-03-18 Thread Sebastien Flaesch
Hello, I am looking at pgvector, pgvectorscale, pgai extensions. Other DB engines support built-in vector types. Is there a plan to get pgvector's types (vector, halfvec, sparsevec, bit) implemented as native built-in data types like json/jsonb ? Side note: I have some doubts about these type

Re: After upgrading libpq, the same function(PQftype) call returns a different OID

2025-03-18 Thread Adrian Klaver
On 3/16/25 02:30, Sebastien Flaesch wrote: Hello, I think the column type identification with PQftype() needs some review/clarification. It's a pity that libpq does not have an API to return directly the actual type name of a column. The doc

Re: BUG #18575: Sometimes pg_rewind mistakenly assumes that nothing needs to be done.

2025-03-18 Thread Evgeniy Ratkov
On 08/09/2024 15:26, Heikki Linnakangas wrote: > 2. Independently of pg_rewind: When you start PostgreSQL, it will first > try to recover all the WAL it has locally in pg_wal. That goes wrong if > you have set a recovery target TLI. For example, imagine this situation: > > - Recovery target TLI i

Re: Cannot pg_dump_all anymore...

2025-03-18 Thread Ron Johnson
On Tue, Mar 18, 2025 at 5:14 AM E-BLOKOS wrote: > I got this error: > > pg_dump: error: query returned 0 rows instead of one: EXECUTE > dumpBaseType('794978') > > any clue to solve it? > PG version? Whole command line, including all error messages? -- Death to , and butter sauce. Don't boil m

Re: Cannot pg_dump_all anymore...

2025-03-18 Thread Greg Sabino Mullane
First figure out which database is having that issue, by using pg_dump --schema-only on each database in turn. Then run this SQL on the database giving the error to see if the type exists, or what is nearby: select oid, typname, typtype, typnamespace::regnamespace from pg_type where oid <= 794978

Cannot pg_dump_all anymore...

2025-03-18 Thread E-BLOKOS
I got this error: pg_dump: error: query returned 0 rows instead of one: EXECUTE dumpBaseType('794978') any clue to solve it? thanks David