Abbreviation list

Steve Crawford wrote:

Is there a comprehensive (or semi-comprehensive) on-line list of
commonly used PG-related abbreviations used in PostgreSQL documentation,
mail-lists, etc.? If there is not, would such a list make a reasonable
one-page addition to the PG manual?

I don't think we have one, but IMHO it would be an excellent idea. We
do have some abbreviations, e.g. HOT, TOAST, WAL are the ones that
jump immediately to mind (besides the ones you mentioned).

--
Alvaro Herrera http://www.amazon.com/gp/registry/5ZYLFMCVHXC
"Granting software the freedom to evolve guarantees only different results,
not better ones." (Zygo Blaxell)

Alvaro Herrera wrote:

Steve Crawford wrote:

Is there a comprehensive (or semi-comprehensive) on-line list of
commonly used PG-related abbreviations used in PostgreSQL documentation,
mail-lists, etc.? If there is not, would such a list make a reasonable
one-page addition to the PG manual?

I don't think we have one, but IMHO it would be an excellent idea. We
do have some abbreviations, e.g. HOT, TOAST, WAL are the ones that
jump immediately to mind (besides the ones you mentioned).

My vote is to add "Appendix I. Abbreviations". Don't know if it's
practical for 8.3 documentation but it would be nice to add even if it
only has a few entries as additional ones could be collected via the
user notes.

I suggest as a discussion starting-point the following inclusion criteria:

1. Any abbreviation/acronym that appears in the PostgreSQL documentation
(even if those terms may not be PG specific - we shouldn't assume that
everyone knows them). Good documentation practice recommends defining
abbreviations the first time they are used. Better still, ensure that
they are in the abbreviation list.

2. PostgreSQL-specific abbreviations/acronyms commonly used in on-line
conversations, news-releases, notes, etc. even if not (or not yet) in
the official documentation.

3. Abbreviations/acronyms that do not meet criteria 1 or 2 but which are
likely to clarify PG related conversations (optional, lower priority and
within the limitations of avoiding appendix bloat).

So BSD, STONITH, DBA, DBMS, RDBMS, GEQO would meet both criteria 1 and
criteria 2.

GUC and DDL (currently) only meet the second criteria.

A starter list mostly gleaned from PG documentation (typing defs quickly
and from memory - feel free to make corrections):

BKI - Backend Interface
CID - Command Identifier
CLI - Call Level Interface / Command Line Interface
CVE - Common Vulnerabilities and Exposures
CVS - Concurrent Version System
DBA - Database Administrator
DBMS - Database Management System
DDL - Data Definition Language
DML - Data Manipulation Language
DSN - Data Source Name
ECPG - Embedded SQL in C ??
GEQO - Genetic Query Optimizer
GIN - Generalized Inverted Index
GIST - Generalized Search Tree
GNU - Gnu's Not Unix
GSSAPI - Generic Security Services Application Programming Interface
GUC - Global User Configuration
HOT - Heap Oriented Tuples
IEC - International Electrotechnical Commission
ISO - International Standards Organization
JDBC - Java Database Connectivity
JRT - Java Routines and Types
LDAP - Lightweight Directory Access Protocol
MED - Management of External Data
MVCC - Multi Version Concurrency Control
NLS - Natural Language Support
ODBC - Open Database Connectivity
OID - Object Identifier
OLAP - Online Analytical Processing
OLB - Object Language Bindings
PAM - Pluggable Authentication Modules
PITR - Point In Time Recovery
POSIX - Portable Operating System Interface
PSM - Persistent Stored Modules
RPM - Redhat Package Manager
SSPI - Security Support Provider Interface
SQL - Structured Query Language
SSL - Secure Sockets Layer
STONITH - Shoot The Other Node In The Head
TOAST - The Oversize Attribute Storage Technique
UUID - Universally Unique Identifier
WAL - Write Ahead Log
XID - Transaction Identifier
XML - Extensible Markup Language

Cheers,
Steve

Steve Crawford <scrawford@pinpointresearch.com> writes:

My vote is to add "Appendix I. Abbreviations".

It seems more like FAQ material than something for the manual.

regards, tom lane

Tom Lane wrote:

Steve Crawford <scrawford@pinpointresearch.com> writes:

My vote is to add "Appendix I. Abbreviations".

It seems more like FAQ material than something for the manual.

I prefer the manual. I would think the list would be pretty long and
deal with lots of internals terms.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

I prefer the manual. I would think the list would be pretty long and
deal with lots of internals terms.

Also the manual has more "reference" character; as we saw with GUC in
this discussion it is still possible to find a CORRECT definition of
them.

Harald

--
GHUM Harald Massa
persuadere et programmare
Harald Armin Massa
Spielberger Straße 49
70435 Stuttgart
0173/9409607
fx 01212-5-13695179
-
EuroPython 2008 will take place in Vilnius, Lithuania - Stay tuned!

Steve Crawford wrote:

My vote is to add "Appendix I. Abbreviations". Don't know if it's
practical for 8.3 documentation but it would be nice to add even if it
only has a few entries as additional ones could be collected via the
user notes.

I suggest as a discussion starting-point the following inclusion criteria:

1. Any abbreviation/acronym that appears in the PostgreSQL documentation
(even if those terms may not be PG specific - we shouldn't assume that
everyone knows them). Good documentation practice recommends defining
abbreviations the first time they are used. Better still, ensure that
they are in the abbreviation list.

Isn't this just what the ABBR tag in html is for?

--
Alban Hertroys
a.hertroys@magproductions.nl

magproductions b.v.

T: ++31(0)534346874
F: ++31(0)534346876
M:
I: www.magproductions.nl
A: Postbus 416
7500 AK Enschede

// Integrate Your World //

Alban Hertroys schrieb:

Steve Crawford wrote:

My vote is to add "Appendix I. Abbreviations". Don't know if it's
practical for 8.3 documentation but it would be nice to add even if it
only has a few entries as additional ones could be collected via the
user notes.

I suggest as a discussion starting-point the following inclusion criteria:

1. Any abbreviation/acronym that appears in the PostgreSQL documentation
(even if those terms may not be PG specific - we shouldn't assume that
everyone knows them). Good documentation practice recommends defining
abbreviations the first time they are used. Better still, ensure that
they are in the abbreviation list.

Isn't this just what the ABBR tag in html is for?

Well, yes; according w3.org its purpose is to describe the
abbreviation/acronym inline in a document using a title attribute:

<acronym title="Grand Unified Configuration">GUC</acronym>

Firefox by default underlines the abbreviation with a dotted line and
displays the title when leaving the cursor on it. In a way this means
probably defining the abbreviation.

Reference: http://www.w3.org/TR/html401/struct/text.html#edef-ABBR

--
Thomas Pundt <thomas.pundt@rp-online.de> ---- http://rp-online.de/ ----

Thomas Pundt wrote:

Alban Hertroys schrieb:

Isn't this just what the ABBR tag in html is for?

Well, yes; according w3.org its purpose is to describe the
abbreviation/acronym inline in a document using a title attribute:

Can you do that from a SGML DocBook source?

--
Alvaro Herrera http://www.amazon.com/gp/registry/DXLWNGRJD34J
"The West won the world not by the superiority of its ideas or values
or religion but rather by its superiority in applying organized violence.
Westerners often forget this fact, non-Westerners never do."
(Samuel P. Huntington)

On Fri, 19 Oct 2007 10:59:20 -0300
Alvaro Herrera <alvherre@commandprompt.com> wrote:

Thomas Pundt wrote:

Alban Hertroys schrieb:

Isn't this just what the ABBR tag in html is for?

Well, yes; according w3.org its purpose is to describe the
abbreviation/acronym inline in a document using a title attribute:

Can you do that from a SGML DocBook source?

http://www.oasis-open.org/docbook/documentation/reference/html/acronym.html

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240
PostgreSQL solutions since 1997 http://www.commandprompt.com/
UNIQUE NOT NULL
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/

Joshua D. Drake wrote:

On Fri, 19 Oct 2007 10:59:20 -0300
Alvaro Herrera <alvherre@commandprompt.com> wrote:

Thomas Pundt wrote:

Alban Hertroys schrieb:

Isn't this just what the ABBR tag in html is for?

Well, yes; according w3.org its purpose is to describe the
abbreviation/acronym inline in a document using a title attribute:

Can you do that from a SGML DocBook source?

http://www.oasis-open.org/docbook/documentation/reference/html/acronym.html

That seems pretty useless.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

On Fri, 19 Oct 2007 14:28:30 -0300
Alvaro Herrera <alvherre@commandprompt.com> wrote:

Joshua D. Drake wrote:

On Fri, 19 Oct 2007 10:59:20 -0300
Alvaro Herrera <alvherre@commandprompt.com> wrote:

Thomas Pundt wrote:

Alban Hertroys schrieb:

Isn't this just what the ABBR tag in html is for?

Well, yes; according w3.org its purpose is to describe the
abbreviation/acronym inline in a document using a title
attribute:

Can you do that from a SGML DocBook source?

http://www.oasis-open.org/docbook/documentation/reference/html/acronym.html

That seems pretty useless.

*shrug*

Joshua D. Drake

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240
PostgreSQL solutions since 1997 http://www.commandprompt.com/
UNIQUE NOT NULL
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/

On Thu, Oct 18, 2007 at 04:46:00PM -0700, Steve Crawford wrote:

ECPG - Embedded SQL in C ??

Correct. And the PG part should be obvious. :-)

Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!

On Fri, 19 Oct 2007 20:04:27 +0200
Michael Meskes <meskes@postgresql.org> wrote:

On Thu, Oct 18, 2007 at 04:46:00PM -0700, Steve Crawford wrote:

ECPG - Embedded SQL in C ??

Correct. And the PG part should be obvious. :-)

Pretty Good?

Michael

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240
PostgreSQL solutions since 1997 http://www.commandprompt.com/
UNIQUE NOT NULL
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/

Bruce Momjian wrote:

Tom Lane wrote:

Steve Crawford <scrawford@pinpointresearch.com> writes:

My vote is to add "Appendix I. Abbreviations".

It seems more like FAQ material than something for the manual.

I prefer the manual. I would think the list would be pretty long and
deal with lots of internals terms.

My vote too. Just noticed I missed (probably one of many):
BLOB - Binary Large Object

Cheers,
Steve

Steve Crawford wrote:

Bruce Momjian wrote:

Tom Lane wrote:

Steve Crawford <scrawford@pinpointresearch.com> writes:

My vote is to add "Appendix I. Abbreviations".

It seems more like FAQ material than something for the manual.

I prefer the manual. I would think the list would be pretty long and
deal with lots of internals terms.

My vote too. Just noticed I missed (probably one of many):
BLOB - Binary Large Object

Do we use that term? Normally for us it's "large objects".

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

On Oct 19, 2007, at 1:20 PM, Steve Crawford wrote:

Bruce Momjian wrote:

Tom Lane wrote:

Steve Crawford <scrawford@pinpointresearch.com> writes:

My vote is to add "Appendix I. Abbreviations".

It seems more like FAQ material than something for the manual.

I prefer the manual. I would think the list would be pretty long and
deal with lots of internals terms.

My vote too. Just noticed I missed (probably one of many):
BLOB - Binary Large Object

As far as missed goes, I believe I saw OLAP but not OLTP.

Erik Jones

Software Developer | Emma®
erik@myemma.com
800.595.4401 or 615.292.5888
615.292.0777 (fax)

Emma helps organizations everywhere communicate & market in style.
Visit us online at http://www.myemma.com

Alvaro Herrera wrote:

Steve Crawford wrote:

Bruce Momjian wrote:

Tom Lane wrote:

Steve Crawford <scrawford@pinpointresearch.com> writes:

My vote is to add "Appendix I. Abbreviations".

It seems more like FAQ material than something for the manual.

I prefer the manual. I would think the list would be pretty long and
deal with lots of internals terms.

My vote too. Just noticed I missed (probably one of many):
BLOB - Binary Large Object

Do we use that term? Normally for us it's "large objects".

Perhaps we should add "LO" but the documentation does refer to the term
BLOB though typically in the context of "The SQL standard defines a
different binary string type, called BLOB..." or in the list of reserved
words.

Cheers,
Steve

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/19/07 14:36, Alvaro Herrera wrote:

Steve Crawford wrote:

Bruce Momjian wrote:

Tom Lane wrote:

Steve Crawford <scrawford@pinpointresearch.com> writes:

My vote is to add "Appendix I. Abbreviations".

It seems more like FAQ material than something for the manual.

I prefer the manual. I would think the list would be pretty long and
deal with lots of internals terms.

My vote too. Just noticed I missed (probably one of many):
BLOB - Binary Large Object

Do we use that term? Normally for us it's "large objects".

Good news everyone! "Large objects" is generic enough that if PG is
ever ported to the IBM 1400 that you won't have to come up with a
new acronym: DLOB (Decimal Large OBject).

- --
Ron Johnson, Jr.
Jefferson LA USA

Give a man a fish, and he eats for a day.
Hit him with a fish, and he goes away for good!

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHGRT8S9HxQb37XmcRAvnnAJwO9RVzeNwFWh5hCdQNnUihDuy2QQCeJyUL
SHMDqqSUmIPbTLU5d+/LmKI=
=y/Vu
-----END PGP SIGNATURE-----

Hi,

Le Friday 19 October 2007 22:29:37 Steve Crawford, vous avez écrit :

Do we use that term? Normally for us it's "large objects".

Perhaps we should add "LO" but the documentation does refer to the term
BLOB though typically in the context of "The SQL standard defines a
different binary string type, called BLOB..." or in the list of reserved
words.

This topic was discussed on IRC the other day, and we seemed to conclude that
what standard SQL refers to as CLOB and BLOB can be compared to PostgreSQL
text and bytea types with TOAST storage, which makes them out-of-line text or
binary objects.
Large Objects seems to be another beast when compared to blobs...

As I'm still pretty ignorant on the matter, though, I'd appreciate it if some
light was to be made ;)

Regards,
--
dim