Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1u1X6C-003xKu-NP for pgsql-general@arkaria.postgresql.org; Sun, 06 Apr 2025 21:00:12 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1u1X6A-002jIb-SO for pgsql-general@arkaria.postgresql.org; Sun, 06 Apr 2025 21:00:11 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1u1X6A-002jIS-FU for pgsql-general@lists.postgresql.org; Sun, 06 Apr 2025 21:00:10 +0000 Received: from mail-lj1-x22e.google.com ([2a00:1450:4864:20::22e]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1u1X68-003LV3-3D for pgsql-general@postgresql.org; Sun, 06 Apr 2025 21:00:09 +0000 Received: by mail-lj1-x22e.google.com with SMTP id 38308e7fff4ca-3061513d353so41471391fa.2 for ; Sun, 06 Apr 2025 14:00:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743973206; x=1744578006; darn=postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=5Dt1IkgSoYLXgn0hlV13ClfDRAUBl+JCtMbUpxmcY0g=; b=hx65poe7506h3baCW7AI+JDjtANBYTIhRjTs81LuXl/imdgfvMVPH2g/cHbfLz8WG8 sJyHlgtT4EEuWM59DsSdECp7AdJMuximsagluKekTCbJII+QKfqjav11263SKZZfW03N tLal6RsRhTA0cISN0S8xMWwF7moc4+V5TX2Pux0Po4L1hnP1oWDnloX9bDs4K4EyCyQ+ Ikhxc12FWn1Wkc1aoghisQO6d8IiiRJxo27XVfweD/dbeV/SMgNyQaQV/qwrsln2uxc1 blzE4+oKsYuF8dTrl6NKGyZkJCsf1A9Xdjay5iWX80BaRQia6crYGViSQJEy2xf/8fF7 3wVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743973206; x=1744578006; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=5Dt1IkgSoYLXgn0hlV13ClfDRAUBl+JCtMbUpxmcY0g=; b=kOjnFOtIsTqIDKF6PC2k9kNcegcwQGckzRzS9l/PHETN4Ywriqo03V5LwMctQUMt06 gzA2ZGrBH/aAZd6fkKwdKUx85prOnBFyzth9AKUyhkvzRnMNcGnPbJvNQsizTGYOMTz2 i3huCvvASnvl0SX442V8WlWn7+xNbJI/2jTpdQAq3I30BWgvr0mzNPVl+7NBjgioO7iL u42lCu+lw7OFZZLTwRBnP+TrTB8HIKGJhbFU4PRXFUgLuiIPiKov8rdXyLrkSu+63Yvg w8pNk/g+9AKyxBpS3cjFU7hopon4JfJWWS3uhgWt8EK1AOleQAXJ3p/RHIhlPSPntLqF 8FkQ== X-Forwarded-Encrypted: i=1; AJvYcCWioTPnEkzsdsv5N2WLPf+upORagqdgSQJCyO2v7neX5fxYStVxj756HA0r+UQQ2n+D7nsHDZP51AqbVR6Q@postgresql.org X-Gm-Message-State: AOJu0YxQSIcGlU7ZW42lQY1sVc31Ul3QAEY87qdqBcfT7aU8odbNKaNe a2xM0Frf0aYCCdTBoSdpao/4IlRcjhQe3ELUr8ZSBBmEP4hGTlBbzjpHSOQ1148QdALc3An27qb dm7ZvwAzqXF9w3EjijIFnyIWu8Kc= X-Gm-Gg: ASbGncsSYS4o06TwU30XswM/TyUhMw56+2iLIsV1uFjDDf8LM2UcmTAmbtUvB9mp9id psWE5Zj88zX2dmraiAD7jgmqcuW6aToZG9zk5SnDYTho2rFhe6UBTdIfZjlOIpfxFNX2yITadWX DaW4ItjDorAibpjg31ERDjZ4UgOj9lXvCEkpxajIREJKq0yCMJ/uG2Z3ISdkQQ X-Google-Smtp-Source: AGHT+IHZBtdLdF3AsvOPBPRj1nZyw8UqgTpmtp+UsNUm11BOJDqxX1Bmd9SGQ9FM6xpQbgXAgZ8DnsZ1JsZgCGo7PpU= X-Received: by 2002:a2e:bd83:0:b0:30b:badf:75fd with SMTP id 38308e7fff4ca-30f164eb94dmr18641951fa.1.1743973206223; Sun, 06 Apr 2025 14:00:06 -0700 (PDT) MIME-Version: 1.0 References: <558AE558-C724-435B-9F32-F40966A20907@thebuild.com> In-Reply-To: <558AE558-C724-435B-9F32-F40966A20907@thebuild.com> From: Merlin Moncure Date: Sun, 6 Apr 2025 15:59:51 -0500 X-Gm-Features: ATxdqUHydzFpKZYg9R5rJc2ZzTXrCXLNNt9U85aILSOIn3Gftpx29WSeIvhdp_U Message-ID: Subject: Re: pgvector as standard PostgreSQL feature? To: Christophe Pettus Cc: Sebastien Flaesch , "pgsql-general@postgresql.org" Content-Type: multipart/alternative; boundary="0000000000007471480632226723" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000007471480632226723 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Mar 19, 2025 at 3:20=E2=80=AFAM Christophe Pettus wrote: > > > > On Mar 19, 2025, at 07:47, Sebastien Flaesch > wrote: > 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 assum= ed > lightly. Once a type is in core, it (almost) never can be removed, and t= he > more specialized the type and detailed the implementation, the greater th= e > 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... a= nd > "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 burni= ng > 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. > Managed offerings are the norm now, so there really is big difference between core and non-core extension, unless your extension is popular enough (as pgvector is) to be supported across the major providers or only requires SQL to deploy. Your point about core is valid, but there is definitely a squeeze on that is preventing ecosystem expansion, don't know what the solution is though. merlin --0000000000007471480632226723 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Mar 19, 2025 at 3:20=E2=80=AFAM C= hristophe Pettus <xof@thebuild.com> wrote:


> On Mar 19, 2025, at 07:47, Sebastien Flaesch <
sebastien.flaesch@4js.com>= wrote:
2. Adding a type to the core distribution (or even to contrib/) creates a m= aintenance burden on the core developers, and that's not something assu= med lightly.=C2=A0 Once a type is in core, it (almost) never can be removed= , and the more specialized the type and detailed the implementation, the gr= eater the risk that the developers who know and care about it won't be = available in the future.=C2=A0 Search the archives for a discussion of the = "money" type for what happens when a type added to core starts be= coming ill-supported... and "money" isn't anywhere near as co= mplex as vector functionality.

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

It is true that hosted environments take time to adopt new extensions (alth= ough AWS RDS has supported pgvector for nearly two years now), but that'= ;s not in itself a reason to move things into core.
Managed offerings are the norm now, so there really is big dif= ference=C2=A0between core and non-core extension, unless your extension is = popular enough (as pgvector=C2=A0is) to be supported across the major provi= ders or only requires=C2=A0SQL to deploy.=C2=A0 =C2=A0 Your point about cor= e is valid, but there is definitely a squeeze on that is preventing ecosyst= em expansion, don't know what the solution is though.

merlin

=C2=A0
--0000000000007471480632226723--