Thread: Describing Postgres as "object-relational" on the home page
Hi, I don't want to start bikeshedding here but maybe the answer is simple. The PG home page calls PG "object-relational". I question whether this is useful. Unlike in the 90's, nobody is really interested any more in object-oriented-everything and the typical person reading the home page probably does not know what an object-relational db is anyway. It may be better to just say "relational". In my opinion simpler is more clear and therefore better. (If another adjective is necessary I like "advanced". I feel it balances "powerful" and, in a sense, substitutes for the "object" qualifer. Because PG is more than just object-relational.) I am only asking whether the home page should be changed. Changing the "object-relational" description elsewhere/everywhere is another matter entirely. I suppose I think this because I think the home page has a different, less sophisticated, audience. For my off-the-cuff mini-rant on this topic see the PostgeSQL Wikipedia talk page: Describing PG as relational v.s. object-relational in the lead https://en.wikipedia.org/wiki/Talk:PostgreSQL#Describing_PG_as_relational_v.s._object-relational_in_the_lead FWIW, I know of at least 4 toggles between "relational" and "object-relational" on the wikipedia page. (It's been just "relational" for some time, but recently toggled back and forth. Feel free to explain on the talk page and change it from the current "relational" to "object-relational". I won't undo. I wrote the talk page entry mostly to keep the postgres-ignorant wikipedia enthusiasts from copy-pasting from the PG home page.) This is not worth spending much time on but I wanted to raise the issue, hoping it can be quickly resolved. There seems to be no discussion in the pgsql-www mailing list archive. Regards, Karl <kop@karlpinc.com> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
On Tue, Dec 26, 2023 at 01:10:47PM -0600, Karl O. Pinc wrote: > Hi, > > I don't want to start bikeshedding here but maybe > the answer is simple. > > The PG home page calls PG "object-relational". I question > whether this is useful. Unlike in the 90's, nobody is > really interested any more in object-oriented-everything > and the typical person reading the home page probably > does not know what an object-relational db is anyway. > > It may be better to just say "relational". I guess if I had to name this with no precedence, I would call it relational/extendable, but that seems even worse that what we have. I do think we need something to explain that Postgres is more than simply relational since our extendibility, along with our open source development, are what make us popular. I agree "object" isn't a great word, and as I heard was just used in the 1990's because object languages were the hot topic. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EDB https://enterprisedb.com Only you can decide what is important to you.
Bruce Momjian <bruce@momjian.us> writes:
> On Tue, Dec 26, 2023 at 01:10:47PM -0600, Karl O. Pinc wrote:
>> It may be better to just say "relational".
> I guess if I had to name this with no precedence, I would call it
> relational/extendable, but that seems even worse that what we have.
Call it an "extensible relational database"? I agree that the
"object" part is out of date and no longer much of a focal point.
regards, tom lane
On 12/26/23 22:21, Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: >> On Tue, Dec 26, 2023 at 01:10:47PM -0600, Karl O. Pinc wrote: >>> It may be better to just say "relational". > >> I guess if I had to name this with no precedence, I would call it >> relational/extendable, but that seems even worse that what we have. > > Call it an "extensible relational database"? I agree that the > "object" part is out of date and no longer much of a focal point. Especially considering we hardly implement any of the object features at all. We have table inheritance, and that's about it. -- Vik Fearing
On Tue, Dec 26, 2023 at 10:49:16PM +0100, Vik Fearing wrote: > On 12/26/23 22:21, Tom Lane wrote: > > Bruce Momjian <bruce@momjian.us> writes: > > > On Tue, Dec 26, 2023 at 01:10:47PM -0600, Karl O. Pinc wrote: > > > > It may be better to just say "relational". > > > > > I guess if I had to name this with no precedence, I would call it > > > relational/extendable, but that seems even worse that what we have. > > > > Call it an "extensible relational database"? I agree that the > > "object" part is out of date and no longer much of a focal point. > > Especially considering we hardly implement any of the object features at > all. We have table inheritance, and that's about it. "extensible relational database" works for me. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EDB https://enterprisedb.com Only you can decide what is important to you.
On 12/26/23 5:40 PM, Bruce Momjian wrote: > On Tue, Dec 26, 2023 at 10:49:16PM +0100, Vik Fearing wrote: >> On 12/26/23 22:21, Tom Lane wrote: >>> Bruce Momjian <bruce@momjian.us> writes: >>>> On Tue, Dec 26, 2023 at 01:10:47PM -0600, Karl O. Pinc wrote: >>>>> It may be better to just say "relational". >>> >>>> I guess if I had to name this with no precedence, I would call it >>>> relational/extendable, but that seems even worse that what we have. >>> >>> Call it an "extensible relational database"? I agree that the >>> "object" part is out of date and no longer much of a focal point. >> >> Especially considering we hardly implement any of the object features at >> all. We have table inheritance, and that's about it. > > "extensible relational database" works for me. Reading [1], I can align with dropping "object-" from the text. Currently -1 on swapping it with "extensible", given most folks describe PostgreSQL as a relational database. That said, I do personally describe one of PostgreSQL's best attributes to be its "extensibility," so I could warm up to incorporating it into "official verbiage" in the coming days. Jonathan [1] https://en.wikipedia.org/wiki/Object%E2%80%93relational_database
Attachment
On 12/27/23 13:53, Jonathan S. Katz wrote: > On 12/26/23 5:40 PM, Bruce Momjian wrote: >> On Tue, Dec 26, 2023 at 10:49:16PM +0100, Vik Fearing wrote: >>> On 12/26/23 22:21, Tom Lane wrote: >>>> Bruce Momjian <bruce@momjian.us> writes: >>>>> On Tue, Dec 26, 2023 at 01:10:47PM -0600, Karl O. Pinc wrote: >>>>>> It may be better to just say "relational". >>>> >>>>> I guess if I had to name this with no precedence, I would call it >>>>> relational/extendable, but that seems even worse that what we have. >>>> >>>> Call it an "extensible relational database"? I agree that the >>>> "object" part is out of date and no longer much of a focal point. >>> >>> Especially considering we hardly implement any of the object features at >>> all. We have table inheritance, and that's about it. >> >> "extensible relational database" works for me. > > Reading [1], I can align with dropping "object-" from the text. > > Currently -1 on swapping it with "extensible", given most folks describe > PostgreSQL as a relational database. > > That said, I do personally describe one of PostgreSQL's best attributes > to be its "extensibility," so I could warm up to incorporating it into > "official verbiage" in the coming days. Reading this I got a vision of a cat in a box:) At some point the state has to resolve. Are you indicating that "extensible relational database" is acceptable to you? > > Jonathan > > [1] https://en.wikipedia.org/wiki/Object%E2%80%93relational_database > -- Adrian Klaver adrian.klaver@aklaver.com
Postgres is a fully-relational (in that it simultaneously adheres to all of Codd's rules - something surprisingly rare) multi-paradigm database. It is multi-paradigm because it is also simultaneously a native object database and document database (JSONB support better than MongoDB), plus has ready extensions to be a first class Geodesic Database and Vector Database (ala AI) amongst others.
Just because "object" has become a bad word because of idiots who jump on bandwagons and don't even understand the term does not remove its value. There are still those of us around who used Postgres before it had SQL support and understand how it works internally. Note that all this extensibility is made achievable a great deal because it *is* underneath it all an Object Database. But I agree that we could use better marketing language to express the full potential of this remarkable open source project.
- - Ben Scherrey
On Wed, Dec 27, 2023, 2:11 AM Karl O. Pinc <kop@karlpinc.com> wrote:
Hi,
I don't want to start bikeshedding here but maybe
the answer is simple.
The PG home page calls PG "object-relational". I question
whether this is useful. Unlike in the 90's, nobody is
really interested any more in object-oriented-everything
and the typical person reading the home page probably
does not know what an object-relational db is anyway.
It may be better to just say "relational".
In my opinion simpler is more clear and therefore better.
(If another adjective is necessary I like "advanced". I feel
it balances "powerful" and, in a sense, substitutes
for the "object" qualifer. Because PG is more than
just object-relational.)
I am only asking whether the home page should be changed.
Changing the "object-relational" description elsewhere/everywhere
is another matter entirely. I suppose I think this because
I think the home page has a different, less sophisticated, audience.
For my off-the-cuff mini-rant on this topic see the PostgeSQL
Wikipedia talk page:
Describing PG as relational v.s. object-relational in the lead
https://en.wikipedia.org/wiki/Talk:PostgreSQL#Describing_PG_as_relational_v.s._object-relational_in_the_lead
FWIW, I know of at least 4 toggles between "relational" and
"object-relational" on the wikipedia page. (It's been just
"relational" for some time, but recently toggled back and forth.
Feel free to explain on the talk page and change it from the
current "relational" to "object-relational". I won't
undo. I wrote the talk page entry mostly to keep the
postgres-ignorant wikipedia enthusiasts from copy-pasting
from the PG home page.)
This is not worth spending much time on but I wanted to raise
the issue, hoping it can be quickly resolved. There seems
to be no discussion in the pgsql-www mailing list archive.
Regards,
Karl <kop@karlpinc.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
To keep it simple: PostgreSQL is a powerful, open source, extendable, relational database. It has over 35 years of active development that has earned it a strong reputation for reliability, feature robustness, and performance. (I like multiple, shorter, sentences. And advocate for putting the information which is to be most memorable at the end of sentences and paragraphs.) On Thu, 28 Dec 2023 09:20:39 +0700 Benjamin Scherrey <scherrey@proteus-tech.com> wrote: > Postgres is a fully-relational (in that it simultaneously adheres to > all of Codd's rules - something surprisingly rare) multi-paradigm > database. It is multi-paradigm because it is also simultaneously a > native object database and document database (JSONB support better > than MongoDB), plus has ready extensions to be a first class Geodesic > Database and Vector Database (ala AI) amongst others. > Note that all this extensibility is made achievable a great deal > because it *is* underneath it all an Object Database. But I agree > that we could use better marketing language to express the full > potential of this remarkable open source project. I like the idea of showing more of what PG can do: PostgreSQL is a powerful, open source, extendable, relational database. It is also, or has third-party extensions to become, an object-relational, document/NoSQL, temporal, spatial and geodesic, or vector database. PostgreSQL has over 35 years of active development that has earned it a strong reputation for reliability, feature robustness, and performance. Attached is a tar file of the home page (+CSS, etc., as firefox saves it) with the above change, with new hyperlinks. So you can (sorta) see what it looks like. https://en.wikipedia.org/wiki/Relational_database https://en.wikipedia.org/wiki/Object%E2%80%93relational_database https://en.wikipedia.org/wiki/Nosql https://wiki.postgresql.org/wiki/Temporal_Extensions https://postgis.net https://www.enterprisedb.com/blog/what-is-pgvector I don't know that off-site links to the various db type names is home-page-appropriate but it might help the beginner. I added hyperlinks to (sorta) simple descriptions of the various db types. I tried to stick with wikipedia but went to postgis.net and the pg wiki too. I couldn't find anything on these go-to sites for pg_vector that has a simple overview describing the uses of a vector db, so settled on a commercial link. (Alternately, the wikipedia or wiki.postgresql.org vector database article could be given a better lead. Or a patch sent to pg_vector that gives the README.md a non-technical "for what?".) It would be nice to link to pg_vector, as with the links to the other 3rd-party extensions, but I find it's home page too technical for the average person looking to find out what vector databases are for. There is room, at least the way my browser window opens, for the extra text so that the layout does not change. Regards, Karl <kop@karlpinc.com> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
Attachment
On 12/27/23 5:21 PM, Adrian Klaver wrote: > On 12/27/23 13:53, Jonathan S. Katz wrote: >> On 12/26/23 5:40 PM, Bruce Momjian wrote: >>> On Tue, Dec 26, 2023 at 10:49:16PM +0100, Vik Fearing wrote: >>>> On 12/26/23 22:21, Tom Lane wrote: >>>>> Bruce Momjian <bruce@momjian.us> writes: >>>>>> On Tue, Dec 26, 2023 at 01:10:47PM -0600, Karl O. Pinc wrote: >>>>>>> It may be better to just say "relational". >>>>> >>>>>> I guess if I had to name this with no precedence, I would call it >>>>>> relational/extendable, but that seems even worse that what we have. >>>>> >>>>> Call it an "extensible relational database"? I agree that the >>>>> "object" part is out of date and no longer much of a focal point. >>>> >>>> Especially considering we hardly implement any of the object >>>> features at >>>> all. We have table inheritance, and that's about it. >>> >>> "extensible relational database" works for me. >> >> Reading [1], I can align with dropping "object-" from the text. >> >> Currently -1 on swapping it with "extensible", given most folks >> describe PostgreSQL as a relational database. >> >> That said, I do personally describe one of PostgreSQL's best >> attributes to be its "extensibility," so I could warm up to >> incorporating it into "official verbiage" in the coming days. > > Reading this I got a vision of a cat in a box:) At some point the state > has to resolve. Are you indicating that "extensible relational database" > is acceptable to you? There is a Schrödinger element here. I agree that "extensible relational database" does accurately describe PostgreSQL, but I'm hesitant to change the official language (outside of dropping "object") without thinking more about it. I don't think we necessarily need to rush adding another word without testing it a bit more. Jonathan
Attachment
On 12/28/23 2:54 PM, Karl O. Pinc wrote: > To keep it simple: > > PostgreSQL is a powerful, open source, extendable, > relational database. It has over 35 years of active > development that has earned it a strong reputation for > reliability, feature robustness, and performance. > I'd be content with this (including extensible for now): PostgreSQL is a powerful, open source, extensible relational database with over 35 years of active development and a strong reputation for reliability, feature robustness, and performance. > I like the idea of showing more of what PG can do: > > PostgreSQL is a powerful, open source, extendable, > relational database. It is also, or has third-party > extensions to become, an object-relational, document/NoSQL, > temporal, spatial and geodesic, or vector database. > PostgreSQL has over 35 years of active development that > has earned it a strong reputation for reliability, feature > robustness, and performance. > > Attached is a tar file of the home page (+CSS, etc., > as firefox saves it) with the above change, with new > hyperlinks. So you can (sorta) see what it looks like. Thanks -- it's easier to make a diff from pgweb[1] to view, but I can understand that pgweb may be nontrivial to set up :( I'd be open to adding another paragraph that discusses the capabilities, which is not dissimilar to what we do on the "About"[2] page: https://www.postgresql.org/about/ > https://en.wikipedia.org/wiki/Relational_database > https://en.wikipedia.org/wiki/Object%E2%80%93relational_database > https://en.wikipedia.org/wiki/Nosql > https://wiki.postgresql.org/wiki/Temporal_Extensions > https://postgis.net > https://www.enterprisedb.com/blog/what-is-pgvector > > I don't know that off-site links to the various db type names > is home-page-appropriate but it might help the beginner > I added hyperlinks to (sorta) simple descriptions > of the various db types. I tried to stick with wikipedia > but went to postgis.net and the pg wiki too. I couldn't > find anything on these go-to sites for pg_vector that has > a simple overview describing the uses of a vector db, > so settled on a commercial link. (Alternately, the > wikipedia or wiki.postgresql.org vector database article > could be given a better lead. Or a patch sent to pg_vector > that gives the README.md a non-technical "for what?".) I'm a very strong -1 to off-site links from the homepage in this context. This is very valuable real-estate on the .org webpage and carriers heavy weight with SEO engines, so I'd strongly suggest we're careful with what we link to. That said, I'm not opposed to either expanding our own website or wiki to include more info on the above. > It would be nice to link to pg_vector, as with the links > to the other 3rd-party extensions, but I find it's home > page too technical for the average person looking to find > out what vector databases are for. [disclosure: I contribute actively to pgvector] I'd suggest we be careful which projects we call out as well. PostGIS has a long development and adoption history and is one of the well-known building blocks of geospatial applications. pgvector is newer and, while it's popularity has skyrocketed over the past year, there is still lots of active development going on in vector storage and retrieval both in and around pgvector, e.g. other projects may emerge as popular choices. This also brings up the question about how we treat projects that add typical database functionality to PostgreSQL that may not be extension per se, e.g. Patroni, pgBackRest, etc. I'm not saying we don't have links to external projects that showcase PostgreSQL's extensibility, but I'd like to think through how we'd do that given putting such projects/links at the top of the homepage are a quasi-official endorsement. > There is room, at least the way my browser window opens, > for the extra text so that the layout does not change. I think it's a good idea to talk about the types of functionality/workloads PostgreSQL can support, whether in core or extensions (geospatial, time series, vector/AI/pick-the-buzzword, distributed, etc.), and perhaps the starting point is adding that language that suggests that. We can then link to the wiki, perhaps make a "List of Extensions" page that's similar to "List of Drivers"[4] (which [4] is now linked to from the docs) that categorizes them. [5] has a nice starting point on the aggregation of what's out there. Thanks, Jonathan [1] https://git.postgresql.org/gitweb/?p=pgweb.git;a=summary [2] https://www.postgresql.org/about/ [3] https://www.postgresql.org/download/product-categories/ [4] https://wiki.postgresql.org/wiki/List_of_drivers [5] https://gist.github.com/joelonsql/e5aa27f8cc9bd22b8999b7de8aee9d47
Attachment
On Sun, 31 Dec 2023 10:42:11 -0500 "Jonathan S. Katz" <jkatz@postgresql.org> wrote: > I think it's a good idea to talk about the types of > functionality/workloads PostgreSQL can support, whether in core or > extensions (geospatial, time series, vector/AI/pick-the-buzzword, > distributed, etc.), and perhaps the starting point is adding that > language that suggests that. We can then link to the wiki, perhaps > make a "List of Extensions" page that's similar to "List of > Drivers"[4] (which [4] is now linked to from the docs) that > categorizes them. [5] has a nice starting point on the aggregation of > what's out there. > [5] https://gist.github.com/joelonsql/e5aa27f8cc9bd22b8999b7de8aee9d47 There's also https://pgxn.org, the PostgreSQL Extension Network. It's interface, a list of tags with font sizes that correspond to frequency of occurrence, gives me an idea. Give up. Add the sentence "PostgreSQL supports many popular buzzwords, which make it more than a relational database." and link "buzzwords" to a page of buzzwords. Since "buzzword" is so generic, "Geospatial" can appear next to "ACID" next to "SQL" without concern. Each buzzword could link to a google search of "PostgreSQL" + "<buzzword>". To get fancy, let the user choose the search engine. Or really give up and link to a buzzword page on the pg wiki. Regards, Karl <kop@karlpinc.com> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
On 12/31/23 12:40 PM, Karl O. Pinc wrote: > On Sun, 31 Dec 2023 10:42:11 -0500 > "Jonathan S. Katz" <jkatz@postgresql.org> wrote: > >> I think it's a good idea to talk about the types of >> functionality/workloads PostgreSQL can support, whether in core or >> extensions (geospatial, time series, vector/AI/pick-the-buzzword, >> distributed, etc.), and perhaps the starting point is adding that >> language that suggests that. We can then link to the wiki, perhaps >> make a "List of Extensions" page that's similar to "List of >> Drivers"[4] (which [4] is now linked to from the docs) that >> categorizes them. [5] has a nice starting point on the aggregation of >> what's out there. > >> [5] https://gist.github.com/joelonsql/e5aa27f8cc9bd22b8999b7de8aee9d47 > > There's also https://pgxn.org, the PostgreSQL Extension Network. > It's interface, a list of tags with font sizes that correspond to > frequency of occurrence, gives me an idea. > > Give up. Add the sentence "PostgreSQL supports many popular buzzwords, > which make it more than a relational database." > and link "buzzwords" to a page of buzzwords. Since "buzzword" > is so generic, "Geospatial" can appear next to "ACID" next to "SQL" > without concern. Each buzzword could link to a google search of > "PostgreSQL" + "<buzzword>". To get fancy, let the user choose the > search engine. Or really give up and link to a buzzword page on > the pg wiki. I don't really follow what you're suggesting here. I think a bunch of the language you've suggested makes sense for the homepage (and it'll have to be modified in other places); this just needs some iterating and thinking through given the prominence of the language. Given it is the homepage -- and at the very top -- we do need to be careful about what we say/link to, because as I said before, it becomes a quasi-official endorsement. Keeping the generic text does allow us to say that PostgreSQL can handle N different types of workloads, and I think it's fine for us to link to other resources. (Also, having been through many rounds of discussions around external linking, I do think it's prudent we have guidelines for how any external linking is included). To move this along, here is a patch with suggested changes on just the homepage -- as mentioned, we'll likely need to deploy this wider, but I want us to feel comfortable with the language before building a full fledged patch. I took the suggestion of using two sentences in the first paragraph. I don't think the second paragraph is quite there yet, but this should give something to discuss. To make it easier to comment, here are the sentences below: ==quote== PostgreSQL is a powerful, extensible, open source relational database with over 35 years of active development. PostgreSQL has earned a strong reputation for reliability, feature robustness, and performance. PostgreSQL can be used for a wide variety of use-cases, including transactional and analytical workloads. PostgreSQL extensions add more functionality to PostgreSQL, which are used to support geospatial, time series, AI and vector queries, full-text search, distributed systems, and many more workloads. ==quote== Thanks, Jonathan
Attachment
On Sun, 31 Dec 2023 14:40:49 -0500 "Jonathan S. Katz" <jkatz@postgresql.org> wrote: > On 12/31/23 12:40 PM, Karl O. Pinc wrote: > > On Sun, 31 Dec 2023 10:42:11 -0500 > > "Jonathan S. Katz" <jkatz@postgresql.org> wrote: > > > >> I think it's a good idea to talk about the types of > >> functionality/workloads PostgreSQL can support, whether in core or > >> extensions (geospatial, time series, vector/AI/pick-the-buzzword, > >> distributed, etc.), and perhaps the starting point is adding that > >> language that suggests that. We can then link to the wiki, perhaps > >> make a "List of Extensions" page that's similar to "List of > >> Drivers"[4] (which [4] is now linked to from the docs) that > >> categorizes them. [5] has a nice starting point on the aggregation > >> of what's out there. > > > >> [5] > >> https://gist.github.com/joelonsql/e5aa27f8cc9bd22b8999b7de8aee9d47 > >> > > > > There's also https://pgxn.org, the PostgreSQL Extension Network. > > It's interface, a list of tags with font sizes that correspond to > > frequency of occurrence, gives me an idea. > > > > Give up. Add the sentence "PostgreSQL supports many popular > > buzzwords, which make it more than a relational database." > > and link "buzzwords" to a page of buzzwords. Since "buzzword" > > is so generic, "Geospatial" can appear next to "ACID" next to "SQL" > > without concern. Each buzzword could link to a google search of > > "PostgreSQL" + "<buzzword>". To get fancy, let the user choose the > > search engine. Or really give up and link to a buzzword page on > > the pg wiki. > > I don't really follow what you're suggesting here. The suggestion here is to first, change the "object-relational" sentence as has been discussed. (Then, tl,dr; use a interactive "word cloud") But instead of coming up with wording describing functionality, workloads, etc., to simply say "PostgrSQL does lots more stuff." on the home page and link that to a page with nothing but keywords. The keywords can be linked to descriptions or project pages, or not. That way nobody has to write sentences, and more importantly, nobody has to maintain much when there's a new hot technology or figure out what's important enough to put on the home page. Just add a new keyword to the keywords page. (Especially labor free if the keyword page is a pg wiki page.) To extend this idea, just a list of keywords is not engaging. Categorizing the keywords by attaching one or more tags to each opens up possibilities for interaction and alternate ways to view the keywords. In particular the user can find keywords by tag and so keywords need not be categorized in a fixed fashion. This would likely only be interesting if the keywords were linked to somewhere so that after getting a relevant set of keywords the reader could follow the links to find information or tools. In addition to tabular views, the https://pgxn.org sort of view, a "word cloud", provides a useful overview. In this presentation all tags are displayed on a single page but the visual presentation emphasizes those tags that are more important (e.g., occur with more frequency) by displaying them in a larger font. In this view, clicking on any tag shows its associated keywords to facilitate exploration. (From an implementation perspective it might be simplest if each keyword was also a tag, so that there's no need to make a distinction between tags and keywords when searching.) Example: Here are technology keyword/category tag pairs: (CSV file attached) keyword,tag transactions,transactions transactions,SQL standards transactions,data integrity transactions,atomicity consistency,consistency consistency,data integrity constraints,constraints constraints,data integrity constraints,SQL standards isolation,isolation isolation,SQL standards isolation,concurrency atomicity,atomicity atomicity,SQL standards durability,durability durability,data integrity durability,SQL standards SQL,SQL SQL,SQL standards SQL,interfaces geospatial,geospatial geospatial,database types spatial,spatial spatial,database types time series,time series time series,database types temporal,temporal temporal,database types temporal,auditing temporal,security vector,vector vector,database types vector,AI AI,AI failover,failover failover,high availability high availability,high availability clustering,clustering clustering,high availabiltiy clustering,high performance partition,partition partition,high performance table inheritance,table inheritance table inheritance,SQL standards table inheritance,object-relational extensible types,extensible types extensible types,object-relational relational,relational relational,database types client-server,client-server client-server,database types GUI,GUI GUI,interfaces views,views views,interfaces views,SQL standards materialized views,materialized views materialized views,interfaces materialized views,SQL standards materialized views,high performance triggers,triggers triggers,data integrity triggers,SQL standards stored procedures,stored procedures stored procedures,SQL standards stored procedures,high performance row level security,row level security row level security,SQL standards row level security,security SELinux,SELinux SELinux,security table inheritance,table inheritance table inheritance,SQL standards table inheritance,object-relational security,security SQL standards,SQL standards data integrity,data integrity auditing,auditing auditing,security concurrency,concurrency interfaces,interfaces database types,database types high performance,high performance object-relational,object-relational object-relational,database types security,security List of keywords: AI atomicity auditing client-server clustering concurrency consistency constraints database types data integrity durability extensible types failover geospatial GUI high availability high performance interfaces isolation materialized views object-relational partition relational row level security security SELinux spatial SQL SQL standards stored procedures table inheritance temporal time series transactions triggers vector views List of keywords with a "database types" tag: client-server geospatial object-relational relational spatial temporal time series vector And finally, a word cloud image is attached. Of course there are no hyperlinks to the list of tagged keywords as there would be on a web page. Clicking on "database types" would get the above list of database type keywords. (The keywords would then each link to somewhere useful.) Image generated with: cut -d , -f 2 pg_keywords.csv | grep -v '^tag$' | sed 's/ //g' | sed 's/-//g' | wordcloud_cli > pg_keywords.png (There is a python3-wordcloud package in Debian which has wordcloud_cli. https://github.com/amueller/word_cloud Also available at pypi.org.) ) (It occurs to me that "relational" would be much bigger if I was more consistent in using it as a tag.) Perhaps the tuples of keywords, their hyperlink targets, and their tags could be opened up to PG contributors in a wiki-like way. Or maybe have tighter control over the keywords' hyperlinks, given their importance. Accept patches to the keyword/tag db, or whatever makes sense to reduce the maintenance burden while facilitating change. Regards, Karl <kop@karlpinc.com> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
Attachment
On Mon, 1 Jan 2024 13:44:59 -0600
"Karl O. Pinc" <kop@karlpinc.com> wrote:
> instead of coming up with wording describing
> functionality, workloads, etc., to simply say "PostgrSQL does lots
> more stuff." on the home page and link that to a page with nothing
> but keywords.
> To extend this idea, just a list of keywords is not engaging.
> Categorizing the keywords by attaching one or more tags to each opens
> up possibilities for interaction and alternate ways to view the
> keywords.
-- A back of the envelope schema for tagged technology keywords
CREATE TABLE keywords (
keyword TEXT PRIMARY KEY,
url TEXT,
cantag BOOLEAN);
CREATE TABLE taggings (
tag TEXT REFERENCES keywords,
keyword TEXT REFERENCES keywords);
-- And a trigger is needed to ensure that taggings.tag
-- is related to a keywords row having a keywords.cantag value of true.
Regards,
Karl <kop@karlpinc.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
This email contains nothing really new. Feel free to skip it
if you've little interest in a word cloud.
Attached is a corrected CSV file, with "table inheritance"
duplicates removed. (It is only an example data set, but
the duplicates confused things.)
On Mon, 1 Jan 2024 14:15:16 -0600
"Karl O. Pinc" <kop@karlpinc.com> wrote:
> On Mon, 1 Jan 2024 13:44:59 -0600
> "Karl O. Pinc" <kop@karlpinc.com> wrote:
>
> > Categorizing the keywords by attaching one or more tags to each
> > opens up possibilities for interaction and alternate ways to view
> > the keywords.
>
> -- A back of the envelope schema for tagged technology keywords
>
> CREATE TABLE keywords (
> keyword TEXT PRIMARY KEY,
> url TEXT,
> cantag BOOLEAN);
>
> CREATE TABLE taggings (
> tag TEXT REFERENCES keywords,
> keyword TEXT REFERENCES keywords);
>
> -- And a trigger is needed to ensure that taggings.tag
> -- is related to a keywords row having a keywords.cantag value of
> true.
Except that I'd allow/require a row in TAGGINGS for every row in
KEYWORDS, and the Tag and Keyword columns would contain the same
value. That way TAGGINGS will always inner join with KEYWORDS.
FWIW, here's a list of the 12 tags (aka categories) of my example:
AI
atomicity
auditing
concurrency
database types
data integrity
high availability
high performance
interfaces
object-relational
security
SQL standards
Produced by:
ut -d , -f 2 pg_keywords.csv | sort | awk 'BEGIN {last="";}; {if ($0 == last && last != "") print $0; else last = $0};'
|sort -u
The list of tags, and keywords, is what I feel like is missing from the
pgxn.org site's interface. (In their case it's not keywords, but
extensions, that are categorized. They do allow a search-by-typing
rather than having to find the category in the word cloud and click on
it.) It could also be nice if the user was able to omit tags from the
word cloud so that words taking up lots of space can be omitted to
make room for other words.
I am drawn to the idea of being able to search, explain, visualize, and
link directly into, the PostgreSQL ecosystem writ-large.
The tricky work is likely in choosing the links of the keywords. I
would think that a lot of them ("SQL", "SQL standards", "transactions")
have a place already in the documentation. But a lot would go off-site,
or at least I'd think so because the pg wiki does not presently
have enough content and probably shouldn't describe, say,
exactly what "object-relational" means.
(Humm. One of the temporal extensions would really allow this feature
to support wiki-like history and rollback capabilities.
https://wiki.postgresql.org/wiki/Temporal_Extensions
)
Regards,
Karl <kop@karlpinc.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
Attachment
On 1/1/24 11:44, Karl O. Pinc wrote: > On Sun, 31 Dec 2023 14:40:49 -0500 > "Jonathan S. Katz" <jkatz@postgresql.org> wrote: >> I don't really follow what you're suggesting here. > > The suggestion here is to first, change the "object-relational" sentence > as has been discussed. (Then, tl,dr; use a interactive "word cloud") > But instead of coming up with wording describing functionality, > workloads, etc., to simply say "PostgrSQL does lots more stuff." on > the home page and link that to a page with nothing but keywords. > The keywords can be linked to descriptions or project pages, > or not. > > That way nobody has to write sentences, and more importantly, nobody > has to maintain much when there's a new hot technology or > figure out what's important enough to put on the home page. Just add > a new keyword to the keywords page. (Especially labor free if > the keyword page is a pg wiki page.) > > To extend this idea, just a list of keywords is not engaging. > Categorizing the keywords by attaching one or more tags to each opens > up possibilities for interaction and alternate ways to view the > keywords. In particular the user can find keywords by tag and so > keywords need not be categorized in a fixed fashion. > This would likely only be interesting if the keywords were linked to > somewhere so that after getting a relevant set of keywords > the reader could follow the links to find information or tools. Please no, this is just another version of word salad. > > In addition to tabular views, the https://pgxn.org sort of view, > a "word cloud", provides a useful overview. In this presentation all > tags are displayed on a single page but the visual presentation > emphasizes those tags that are more important (e.g., occur > with more frequency) by displaying them in a larger font. > In this view, clicking on any tag shows its associated keywords > to facilitate exploration. > (From an implementation perspective it might be simplest if each > keyword was also a tag, so that there's no need to make a distinction > between tags and keywords when searching.) I actually find that visually distracting and more to the point not that useful. When I go to a site I am looking for something that will scratch my itch, not what is popular. A search box and a table of contents generally is all I need. -- Adrian Klaver adrian.klaver@aklaver.com
On Mon, 1 Jan 2024 14:58:47 -0800
Adrian Klaver <adrian.klaver@aklaver.com> wrote:
> On 1/1/24 11:44, Karl O. Pinc wrote:
> > On Sun, 31 Dec 2023 14:40:49 -0500
> > "Jonathan S. Katz" <jkatz@postgresql.org> wrote:
>
> >> I don't really follow what you're suggesting here.
> >
> > The suggestion here is to first, change the "object-relational"
> > sentence as has been discussed. (Then, tl,dr; use a interactive
> > "word cloud") But instead of coming up with wording describing
> > functionality, workloads, etc., to simply say "PostgrSQL does lots
> > more stuff." on the home page and link that to a page with nothing
> > but keywords. The keywords can be linked to descriptions or project
> > pages, or not.
> >
> > That way nobody has to write sentences, and more importantly, nobody
> > has to maintain much when there's a new hot technology or
> > figure out what's important enough to put on the home page. Just
> > add a new keyword to the keywords page. (Especially labor free if
> > the keyword page is a pg wiki page.)
> >
> > To extend this idea, just a list of keywords is not engaging.
> > Categorizing the keywords by attaching one or more tags to each
> > opens up possibilities for interaction and alternate ways to view
> > the keywords. In particular the user can find keywords by tag and
> > so keywords need not be categorized in a fixed fashion.
> > This would likely only be interesting if the keywords were linked to
> > somewhere so that after getting a relevant set of keywords
> > the reader could follow the links to find information or tools.
>
> Please no, this is just another version of word salad.
Maybe so. Though it seems common and useful to have one
thing categorized into multiple categories. I think
categories guide the inquisitive.
But this is all useless hand-waving, at least for me, because
I'm not volunteering to do the work. Apologies if I've taken
too much of your time.
Regards,
Karl <kop@karlpinc.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
I like the suggested text. I think it's a shame to drop the word object, however. Despite it getting a bad name amongst the academics, it's still very much in use and often quite useful. If someone's searching for an object database I believe Postgres should pop up high in the list. Why remove the term? Totally fine that it's no longer the first term ala "object-relational". -- Ben Scherrey On Mon, Jan 1, 2024 at 2:40 AM Jonathan S. Katz <jkatz@postgresql.org> wrote: > > To move this along, here is a patch with suggested changes on just the > homepage -- as mentioned, we'll likely need to deploy this wider, but I > want us to feel comfortable with the language before building a full > fledged patch. I took the suggestion of using two sentences in the first > paragraph. I don't think the second paragraph is quite there yet, but > this should give something to discuss. > > To make it easier to comment, here are the sentences below: > > ==quote== > PostgreSQL is a powerful, extensible, open source relational database > with over 35 years of active development. PostgreSQL has earned a strong > reputation for reliability, feature robustness, and performance. > > PostgreSQL can be used for a wide variety of use-cases, including > transactional and analytical workloads. PostgreSQL extensions add more > functionality to PostgreSQL, which are used to support geospatial, time > series, AI and vector queries, full-text search, distributed systems, > and many more workloads. > ==quote== > > Thanks, > > Jonathan
On 1/2/24 07:19, Benjamin Scherrey wrote: > I like the suggested text. I think it's a shame to drop the word > object, however. Despite it getting a bad name amongst the academics, > it's still very much in use and often quite useful. If someone's > searching for an object database I believe Postgres should pop up high > in the list. I am curious why you think this. What features of an object database do you think Postgres has to merit ranking high in search results? -- Vik Fearing
On Sun, 31 Dec 2023 14:40:49 -0500
"Jonathan S. Katz" <jkatz@postgresql.org> wrote:
> To move this along, here is a patch with suggested changes on just
> the homepage
> ==quote==
> PostgreSQL is a powerful, extensible, open source relational database
> with over 35 years of active development. PostgreSQL has earned a
> strong reputation for reliability, feature robustness, and
> performance.
>
> PostgreSQL can be used for a wide variety of use-cases, including
> transactional and analytical workloads. PostgreSQL extensions add
> more functionality to PostgreSQL, which are used to support
> geospatial, time series, AI and vector queries, full-text search,
> distributed systems, and many more workloads.
> ==quote==
FWIW, I think temporal databases are much more interesting
than time series databases, which to my understanding are
little more than logs.
Regards,
Karl <kop@karlpinc.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein