Обсуждение: 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

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

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

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

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

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

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

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

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