Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51.11.1\))
Subject: Re: pgvector as standard PostgreSQL feature?
From: Christophe Pettus <xof@thebuild.com>
In-Reply-To: <DBAP191MB12893E8288EBE762637FA86CB0D92@DBAP191MB1289.EURP191.PROD.OUTLOOK.COM>
Date: Wed, 19 Mar 2025 09:19:20 +0100
Cc: "pgsql-general@postgresql.org" <pgsql-general@postgresql.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <558AE558-C724-435B-9F32-F40966A20907@thebuild.com>
References: <DBAP191MB12893E8288EBE762637FA86CB0D92@DBAP191MB1289.EURP191.PROD.OUTLOOK.COM>
To: Sebastien Flaesch <sebastien.flaesch@4js.com>
Archived-At: <https://www.postgresql.org/message-id/558AE558-C724-435B-9F32-F40966A20907%40thebuild.com>
Precedence: bulk


> On Mar 19, 2025, at 07:47, Sebastien Flaesch =
<sebastien.flaesch@4js.com> wrote:
>=20
> Is there a plan to get pgvector's types (vector, halfvec, sparsevec, =
bit) implemented as native built-in data types like json/jsonb ?

(I'm speaking just for myself here.)  I would not base any plans on this =
functionality being available in the PostgreSQL core in the near future =
(and by "near future," I mean the next five years).

1. You list three different extensions with overlapping functionality, =
and that's a good sign that there isn't consensus on what the features =
that would be offered in core should be.

2. Adding a type to the core distribution (or even to contrib/) creates =
a maintenance burden on the core developers, and that's not something =
assumed lightly.  Once a type is in core, it (almost) never can be =
removed, and the more specialized the type and detailed the =
implementation, the greater the risk that the developers who know and =
care about it won't be available in the future.  Search the archives for =
a discussion of the "money" type for what happens when a type added to =
core starts becoming ill-supported... and "money" isn't anywhere near as =
complex as vector functionality.

3. PostgreSQL is designed to have a rich ecosystem of extensions.  The =
ability to add this kind of functionality in an extension is exactly =
what distinguishes PostgreSQL from many other RDBMS systems.  There's no =
burning need to add functionality like this to core.

It is true that hosted environments take time to adopt new extensions =
(although AWS RDS has supported pgvector for nearly two years now), but =
that's not in itself a reason to move things into core.

> Side note: I have some doubts about these type names, especially "bit" =
... why not "bitvec"?

BIT and BIT VARYING are the SQL standard names for these types.

=09