Re: Add A Glossary

From: Jürgen Purtz <juergen(at)purtz(dot)de>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Erik Rijkers <er(at)xs4all(dot)nl>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, Roger Harkavy <rogerharkavy(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, Michael Paquier <michael(at)paquier(dot)xyz>
Subject: Re: Add A Glossary
Date: 2020-05-17 08:09:48
Message-ID: 68649dfb-3c99-d5ca-2edc-e96f3848a890@purtz.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-docs pgsql-hackers

On 17.05.20 08:51, Alvaro Herrera wrote:
> Any object that
> exists in a database is local, regardless of whether it exists in a
> schema or not.
This implies that the term "local" is unnecessary, just call them "SQL
object".
> "Extensions" is one type of object that does not belong
> in a schema. "Foreign data wrapper" is another type of object that does
> not belong in a schema. ... They are*not*
> global objects.
postgres_fdw is a module among many others. It's only an example for
"extensions" and has no different nature. Yes, they are not global SQL
objects because they don't belong to the cluster.

In summary we have 3 types of objects: belonging to a schema, to a
database, or to the cluster (global). Maybe, we can avoid the use of the
different names 'local SQL object' and 'global SQL object' at all and
just call them 'SQL object'. 'global SQL object' is used only once. We
could rephrase "A set of databases and accompanying global SQL objects
... " to "A set of databases and accompanying SQL objects, which exists
at the cluster level, ... "

> TBH I'm not sure of this term at all. I think we sometimes use the
> term "bloat" to talk about the dead rows only, ignoring the free space.

That's a good example for the necessity of the glossary. Currently we
don't have a common understanding about all of our used terms. The
glossary shall fix that and give a mandatory definition - after a
clearing discussion.

--

Jürgen Purtz

In response to

Browse pgsql-docs by date

  From Date Subject
Next Message Jürgen Purtz 2020-05-17 08:44:43 Re: Add A Glossary
Previous Message Alvaro Herrera 2020-05-17 06:51:26 Re: Add A Glossary

Browse pgsql-hackers by date

  From Date Subject
Next Message Jürgen Purtz 2020-05-17 08:44:43 Re: Add A Glossary
Previous Message Dilip Kumar 2020-05-17 07:10:46 Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions