Talk:PostgreSQL/Archive 1

Archive 1

Archive 2

Joins?

Does anyone know about the automagick joins feature in this article? There doesn't seem to be one, but I'm not PostgreSQL expert. Eurleif 15:21, Jan 18, 2004 (UTC)

what's with the criticism section?

I took the criticism section completely out (was renamed shortcomings). It was poorly written and inaccurate. The information that was presented there was more approraite for a PostgreSQL faq entry than on this page.

The few bits of good information (for example: a slony mention) would be more appopriate in a 3rd party support section, etc.

Merlin

It looks like it was written by a Mysql fanatic who dug anything he could in order to make Pgsql look bad. Lack of replication support and native win32 ports are indeed important issues, but the rest doesn't merit being mentioned, IMO.

I agree that the latest item on the "Criticisms" list is badly worded (how about "Due to PostgreSQL's MVCC transaction design, some operations (like count(*)) are slower than one might expect at first."), but I find the criticism list good. All the DBMS pages should have sections on the good/bad sides of the DBMS. That way, Wikipedia may become an interesting and useful encyclopedia, and not just yet another an advocacy advertising pillar. I always feel sceptical when software descriptions don't tell about weaknesses: The rest of the information in such pages becomes dubious. Hopefully, the "Criticisms" section will shrink when PostgreSQL 7.5 is released.

TroelsArvin 18:40, 2 Jun 2004 (UTC)

regarding Due to PostgreSQL's MVCC. I think the specific technical reasons for one or another shortcoming should not be mentioned because it would make the article too bloated. It should be just a list of things that an average user should be aware about when making a decision to use PGSQL. If you don't like wording, reword it. User:Gene s

Uh, when is an "average user" in charge of picking database software? cbraga 13:19, Jun 3, 2004 (UTC)

That depends on a definition of an average user Gene s 14:14, 3 Jun 2004 (UTC)

I think the prevous critisim section was better than the present watered-down version. It's also not a good idea to use statements like Mysql fanatic unless you have any facts to substantiate it. I belive it's wrong to scrap factually correct information because it "makes something look bad". If you don't like wording, reword it. Renaming section is fine, otherwise I want to roll back the latest change.

User:Gene s

Well, I was precisely rewording it. The 'Criticism' section has too many details and does not fit well in this article. It gives the impression that the software is incomplete and unuseable, which is not the case. It mentions many database terms such as COUNT(), 'materialized views', 'updateable views' in a prominent manner which the 'average user' will have no idea what they're about. It mentions replication without giving any hint of why it's important. I really don't think you were justified in rolling back the changes to the original version which I consider inadequate for the reasons I just mentioned, so I'll put mine back on. I suppose it could be complemented if you feel the need, however please stick to the important points. Sorry about the 'fanatic' thing. cbraga 13:19, Jun 3, 2004 (UTC)

No, that's not rewording. You took a factually correct section written by many people over an extended period of time and replaced it with your own which is not as precise or deep. This is not a PGSL advocacy group. It does not matter if correct information makes PGSQL look good or bad. The thing that matters is if it's correct or wrong, readable or not. So, there are two ways to deal with it. (1) Professional, by trying to find a compromise. (2) Unprofessional, by having a roll back fight. I propose the (1) - since you were the last one to roll back my and other people changes, you restore it back and then reword it keeping all the items on the list.

Gene s 14:14, 3 Jun 2004 (UTC)

Well then call it rewriting. Look, sometimes it is necessary to rewrite a whole section of an article because it is not adequate. Such was the case with the criticism section for the reasons I stated before. I don't really care if many shorcomings are listed, only that they are factual and actually relevant to the article. Some of the previous itens were simple inappropriate here. Others gave the false impression that PostgreSQL is an incomplete and unusable product. So I rewrote them into something better: factual, correct and concise. I'm sure you can see that the fact that the original section was written by many people over an extended period of time does not mean it will be well written in the end. In this case, it was not. Also, 'Criticism' is a very poor title choice. You can't criticise software any more than you criticise a hammer. Software and hammers have shortcomings. Thanks. cbraga 23:43, Jun 3, 2004 (UTC)

I have no objection to changing the title. I object to removal of valid points. PGSQL is not suitable for some applications and it should be noted. It's not a good idea to hide problems and let people discover them well into the project. Let's rewrite it some more and put back valid criticism. Gene s 07:07, 4 Jun 2004 (UTC)

I think it's reasonable to compare and contrast the "criticisms" that have been placed in this article with those in the article for MySQL. The MySQL article describes actual criticisms expressed by experts in the field, such as C. J. Date, and the way that MySQL's creators have responded to them. It goes on to describe objective errors in MySQL documentation, and the fact that they have been remedied. It also treats with the response of a part of the user community to MySQL AB's license change. It is not a list of Wikipedia editors' complaints about the product, but a description of a sort of dialogue that has gone on between MySQL's creators and the database community (including MySQL users).

Wikipedia is not supposed to present "original research" or the bare opinions of Wikipedia editors. When we call an article section "Criticisms" it needs to refer to criticisms made by authorities in writing elsewhere. Our own complaints do not fit the bill. --FOo 02:59, 4 Jun 2004 (UTC)

This is a very good idea. Could you provide links to such authoritive opinions so they can be incorporated into the article? I can't completely agree that user opinions are not worthy of inclusion. And I think that issues considered important by PGSQL developers deserve close attention. For example the matter with poor performance of aggregates takes nearly half of the agregates page in the documentation. Need for VACUUM is also a specific feature of PGSQL which is unexpected.

Gene s 07:07, 4 Jun 2004 (UTC)

The statement and the database functions normally while it runs regarding VACUUM is flat out incorrect with PGSQL 7.4 Gene s 14:32, 4 Jun 2004 (UTC)

Quoting from http://www.postgresql.org/docs/7.4/static/maintenance.html#ROUTINE-VACUUMING

Beginning in PostgreSQL 7.2, the standard form of VACUUM can run in parallel with normal database operations (selects, inserts, updates, deletes, but not changes to table definitions). Routine vacuuming is therefore not nearly as intrusive as it was in prior releases, and it's not as critical to try to schedule it at low-usage times of day.

cbraga 16:00, Jun 4, 2004 (UTC)

Can run in parallel is not the same as database functions normally while it runs. Not as critical is simply becuase earlier the database was completely unuseable while it ran. Now it's kind of useful if load is light. It does affect performance A LOT, even with 7.4. Why would it otherwise be adviseable to schedule it at night if it weren't affecting the performance?

Gene s 07:58, 8 Jun 2004 (UTC)

Trivially, any other use of the database server "affects performance". That is, if we measure "performance" by responsiveness to user queries, then the presence of any other activity on the server "affects performance". This would include the activity of another user, or the running of a database dump for backup, or even unrelated activity on the same computer as the database server, as well as a VACUUM.

It's a principle of system administration that one schedules non-time-critical batch processes for times when few time-critical interactive processes are running. This is exactly as true of VACUUM as it is of full backups or any other big, heavy batch process. Making VACUUM sound exceptional in this regard is misleading. --FOo 14:12, 8 Jun 2004 (UTC)

Absolutely correct. Just like stating that it does not affect performance is also misleading (it was so in the previous edition). The current edition seems to fit the bill. Gene s 14:21, 8 Jun 2004 (UTC)

MVCC

The article currently states:

"Concurrency is managed via a Multi-Version Concurrency Control (MVCC) design, which ensures excellent performance even under heavy concurrent access"

Isn't it the case that MVCC improves _read_-concurrency (a read will never block or be blocked) while write concurrency isn't affected?

MVCC improves overall concurrency, since without it a single write operation will lock the full table before proceeding. With MVCC, multiple reads and writes can go on in parallel.

Surely that would depend on how it's implemented? A single write could lock only the row, only the page or perhaps the whole table, depending on the details of the implementation. You don't need to be in the SQL-92 read uncommitted mode, which MVCC appears to be, to have multiple concurrent reads and writes. Jamesday 15:13, 17 July 2005 (UTC)

The whole selling point of MVCC is that you can guarantee read committed isolation without read locks. Or in the serializable isolation level, read locks are acquired, but they do not conflict with concurrent write locks, thus again, improving concurrency. Read [1] for details. -- intgr 10:46, 31 January 2007 (UTC)

Flawed view of the relational model

I changed a few grand (and incorrect) statements wrt the relational model. For example,

Primary among these was the relational model's inability to understand "types", combination of simpler data that make up a single unit. Today we typically refer to these as objects.

Was totally incorrect becuase:

he relational model deals with types quite well.

In 1985, there was no working implementation of the relational model (AFIK there still isn't one)

General sentiments refelect a very common falacy of confusing SQL databases with relational databases (SQL != Relational).

"units" of data are most certainly not referred to as "objects" except within the narrow realm of oo programming. Many statements in the article reflect a heavy bias towards OO philosophies which are certainly not universal in the database world.

Merlin

VACUUM

Vacuuming doesn't actually remove the old data, only marks it such that the space can be reused by new data. Hence the size of the database files on disk does not change. To actually shrink those files you need to do VACUUM FULL which will lock the whole database. Also vacuum full is not usually of any advantadge since an active database would grow again. cbraga 02:28, Jun 11, 2004 (UTC)

Type inheritance?

Could someone please confirm that this is actually correct? It seems to state outright that PostgreSQL has type inheritance, and I'm not sure that it does. Currently the 5th paragraph in the Description section is:

PostgreSQL also allows types to include inheritance, one of the major concepts in object-oriented programming. For instance, one could define a post_code type, and then create us_zip_code and canadian_postal_code based on them. Addresses could then be specialized for us_address and canadian_address, including specialized rules to validate the data in each case.

It's possible that it's referring to table inheritance already described elsewhere, which I don't personally consider quite the same as type inheritance. To the best of my admittedly restricted knowledge, PostgreSQL doesn't have type inheritance. At least, I can't seem to find anything definitive about it on the CREATE TYPE documentation page. It only talks about composite types, base types and array types. There's no mention of inheritance in any of them. Is it an undocumented feature?

Izogi 01:56, 20 Jul 2004 (UTC)

Illustra

This doesn't have anything to do with PostgreSQL

Illustra's product was first introduced in 1991, where it was used in the Sequoia 2000 project late that year. By 1995 the product had added an ability to write plug-in modules they referred to as DataBlades. Unlike other plug-in technologies, with DataBlades external authors could write code to create new low-level datatypes, and tell the database how to store, index and manage it. For instance, one of the most popular DataBlades was used to create a time-series, a list of one particular variable over time, often with gaps. For instance, the price of a stock over time changes, but there are times, like weekends, where the data does not change and there is no entry. Traditional databases have difficultly handling this sort of task; while they can find a record for a particular date, finding the one that is "active" in one of the gaps is time consuming. With the Time Series DataBlade, this was fast and easy.

DataBlades were incredibly successful and started to generate considerable industry "buzz", eventually leading Informix to purchase the company outright in 1996. Industry insiders claimed that it would not be possible to merge the two products, but in fact this was fairly easy because both were based on the original Ingres code and concepts. Informix released their Illustra-based Universal Server in 1997, leaving them in an unchallenged position in terms of technical merit. Roadrunner 22:53, 29 Jul 2004 (UTC)

PostgreSQL v MySQL??!!

We need section about it! where the comparations??

---

Added typical PostgreSQL vs. MySQL flame. I tried to summarize the typical PostgeSQL v. MySQL battle (and to point out that there is a flame war). Ultimately every criticism I've ever seen on the issue was boiled down to one side saying that PostgreSQL was bloated and the other side saying that MySQL was a toy.

Roadrunner 23:10, 29 Jul 2004 (UTC)

You took a section about specific PgSQL shorcomings and turned it into a "typical PostgreSQL vs. MySQL flame" which is cleary NOT what it should be. Your edition appears to be a regression. Gene s 04:06, 30 Jul 2004 (UTC)

MySQL - Fast and simple. Postgresql - Powerful and reliable. 69.31.174.216 (talk) 21:01, 8 January 2008 (UTC)

FYI, there already is a link to point-by-point comparison of several databases in the last line of {{Databases}} at the bottom of this article. --Georgeryp (talk) 17:45, 30 March 2008 (UTC)

"direct understanding of relationships"

I've removed the following text from the page, on the grounds that it is vague and nonsensical. AFAIK, PostgreSQL does not actually have a "direct understanding of the relationships that exist between tables." I suspect that some earlier version of POSTGRES or a related product may have had the capability to do this, but AFAIK PostgreSQL does not. The text is vague about the definition of the tables involved and how exactly this "direct relationship" is established, so perhaps I'm missing something. If someone would care to (a) provide links to the PostgreSQL documentation that discusses this feature (b) provide working SQL that actually takes advantage of this alleged functionality, I'd be happy to re-add the text and rework it to be less vague. Neilc 07:13, 28 Sep 2004 (UTC)

This paragraph is just awful: "The SQL data stores simple data types in "flat tables", requiring the user to gather together related information using queries. " etc A relation is a subset of a cartesian product. Sounds like this was written by an uninformed amateur. user:gtoomey 220.240.152.221 15:13, 19 Jan 2005 (UTC)

Another very useful feature of PostgreSQL involves direct understanding of the relationships that exist between tables. People in the real world typically have several addresses, which the relational model approaches by storing the addresses in one table and the rest of the user information in another. The addresses become "related" to a particular user by storing some unique information, say the user's name, in the address table itself. In order to find all the addresses for "Bob Smith", the user writes a query that "joins" the data back together, by selecting a particular name from the users table and then searching for that name in the address table. Doing a search for all the users in New York can become somewhat complex, requiring the database to find all the user names in the address table, then search the user table for those users. A typical search might look like this:

 SELECT u.* FROM user u, address a WHERE a.city='New York' AND a.user_name=u.user_name

PostgreSQL can explicitly define the relationship between users and addresses. Once defined, the address becomes a property of the user, so the search can be greatly simplified to:

 SELECT * FROM user WHERE address.city='New York'

This code requires no "join": the database itself understands the user.address relationship.

A related example shows the usefulness of types. If one uses PostgreSQL to do:

 SELECT address FROM user

then the database filters the results automatically, returning only those addresses for users, not those for companies or other objects that might also use the address table.

MVCC vs. locks vs. read uncommitted

The recent revision that claimed that MVCC was another name for the "read uncommitted" SQL standard isolation level was mistaken. Postgres provides two isolation levels (read-committed, the default, and serializable); these two levels are implemented via MVCC (MVCC is an implementation technique, whereas the isolation levels describe what behavior is exposed to the user). Also, MVCC does not mean that out of date information is ever returned, merely that multiple versions of tuples are stored in order to decrease locking requirements. MVCC also does not mean that locks are not used -- Postgres uses both locks and MVCC (row-level, page-level, and table-level locks depending on the circumstance). See the chapter on concurrency in the Postgres docs for more information. Neilc 15:18, 17 July 2005 (UTC)

I checked that on the IRC channel prior to making any changes and was told that yes, out of date rows (rows changed by operations started after the beginning of the query) would be returned. The manual page you referenced says the same thing: "This means that while querying a database each transaction sees a snapshot of data (a database version) as it was some time ago, regardless of the current state of the underlying data". Not sure where MVCC belongs - does it really belong there or should it be in some technology section? Probably too obscure to really be in the article, since it seems common to at least PostgreSQl and MySQL.

Talking here about how a query can get a non-exclusive read lock to ensure it's seeing the latest verion of a row, without using SELECT .. FOR UPDATE to get an exclusive write lock and serialised, no concurrency, access it doesn't need. Looks as though that's new for 8.1, currently a development rather than production version. I know the MySQL article distinguishes between what's in development versions and what's in production - should we consistently do it to include development features or consistently do it to set them apart so people know what's released? I know I prefer keeping them apart, since it can take a while for a development version to enter full production release. Jamesday 15:18, 20 July 2005 (UTC)

I'm confused as to what you're talking about. Postgres' behavior is quite standard as far as I know, and does not depend on any new features in 8.1 (8.1 introduces SELECT FOR SHARE, but that is rarely required by applications). As far as "out of date rows" go, it depends on the isolation level. A transaction in serializable isolation level sees a consistent snapshot; if it attempts to UPDATE a row that has been modified by a committed transaction that began after it began (i.e. after its snapshot was defined), it will abort itself (since the two transactions conflict). In read-committed isolation level, a query's snapshot is consistent for the length of the query; new rows added by a committed transaction during the query's execution will not be visible to the transaction, but that is what one would expect. Write conflicts are handled via blocking one of the transactions involved until one transaction has been committed, and then checking the WHERE of the update/delete to see if it is still applicable. The docs describe this in more detail, so I won't go on -- my point is just that I don't see how this is surprising / confusing / undesirable behavior. Neilc 22:25, 24 September 2005 (UTC)

My two cents on MVCC - the previous paragraph by Neilc seems correct to me. Some people seem to be misunderstanding what MVCC is. MVCC never returns "out of date rows" - the data returned is always consistent with what was visible at the start of the transaction. True, it is possible that the data may have been changed by another transaction by this point, but as far as the current transaction is concerned this modification has not yet taken place. MVCC provides an elegant mechanism for achieving such consistency without locking data. Mike.

addons vs. builtin features

Is there merit in distinguishing between these two? For example, some of the "features" in the first list are actually implemented as addons (e.g. PL/PHP, PL/Java, PL/sh, PL/R, PL/Ruby), but I'm not sure there's much to be gained by making the distinction explicit. Anyway, if people think they should be separated, I won't object, but I just wanted to note that there are more addons than just PostGIS. Neilc 15:25, 17 July 2005 (UTC)

Of course. One is what the program as supplied by the vendor does, the other is what you can get other products to do. I don't know PostgreSQL well enough to know all of the add-ons, though, so I only did it for one I was fairly sure of. Would be nice if someone distinguished for the rest, so we have it clear what PostgreSQL's standard distribution does and what other tools do. Jamesday 15:18, 20 July 2005 (UTC)

The addons mentioned here are in the contrib directory of the main distribution. They require an extra command to compile and install, but they are there in the tarball [2]. The full text indexing is moving from a contrib module to the core as of the upcoming 8.3 69.31.174.216 (talk) 21:10, 8 January 2008 (UTC)

History and description

Would not the history section be better after the description and features? It's a fairly dry section, and I can't imagine that's what most people want to read about first.

The description section is also poorly written and needs some cleaning up, as it ranges all over the place, leaning into a little advocacy at times, veering into obscure tangents (e.g. reasons why oo dbs are difficult), and overall is hard to read, especially for a non-technical person.

I also nominate this as the worst sentence: 'The SQL data stores simple data types in "flat tables"' :)

Turnstep 13:44, July 19, 2005 (UTC)

Agreed about history and advocacy - no surprise though - PostgreSQL has some really passionate supporters. Trying to get a non-technical overview is tough for this but it's worth trying, even if the article does have to go into some depth later, because it's the depths which the people who know the field need to know. That discussion of locking above is pretty obscure to most people not involved inwriting programs which use databases but it makes a massive difference when you're handling lots of operations simultaneously and need a guarantee that you're seeing the current data - it's the sort of thing you need when showing stock levels. Jamesday 15:18, 20 July 2005 (UTC)

Mike Stonebraker leaving Berkeley

Mike did not leave Berkeley in 1982, but continued to teach as well as conduct research while he was working at Relational Technology. I know, I was there at Relational Technology. - John Newton

Major Rearrangement

I finally got around to cleaning up the page a lot. It's still in rough shape, but most of the long, boring, lecture like sections are gone. Still needs a lot of work though, but I'm done for now, so have at it. Turnstep 01:15, 6 October 2005 (UTC)

Split off/Create Postgres

I think that there should be a separate Postgres article, with more details on Postgres... 132.205.45.110 18:08, 19 October 2005 (UTC)

Separate from what? Turnstep 18:29, 19 October 2005 (UTC)

market statistics for pgres growth...

i'm writing an open source article for a major online publication and would love to get some statistics for growth in pgres usage, or website stats for the postgresql website or anything that would show some measurement of interst level that goes back at least 5 years.

any ideas?

Such enquiries should be addressed to josh AT postgresql . org --Gsherry 04:55, 14 February 2006 (UTC)

Administration tools

I propose a section listing (and perhaps briefly describing) all major command line and GUI administration tools available for PostgreSQL. Unfortunately I do not have the knowledge to reliably constuct such a section myself. Mike.

I do not think that would fly well; with the PostgreSQL Management Tools article recently deleted (per Wikipedia is not a link directory), I wouldn't suggest anyone to attempt it either. Rather, I'll simply link to {{dmoz|Computers/Software/Databases/PostgreSQL}}. -- intgr 11:29, 31 January 2007 (UTC)

relational database rewrite

I am trying to rewrite relational database and am soliciting opinions. I am particularly interested in bringing in the practical and popular definitions of the term to counter the current article's domination by the "theoretical" crowd. Ideogram 11:13, 11 June 2006 (UTC)

Relational databases, like any other mathematical construct, are not defined by what is popular. The ignorant may think that pi == 22/7 or that SQL NULLs are a relational feature, but that doesn't make it so. --FOo 23:09, 11 June 2006 (UTC)

The term "relational database" is not owned by the mathematicians. The vast majority of people are introduced to the term by claims that Oracle, SQL Server, and PostgreSQL are relational databases. An encyclopedia article is not the place to push your POV that popular usage is "ignorant". Ideogram 00:22, 12 June 2006 (UTC)

The relational model is a mathematical construct. A relational database is a piece of software. Ideogram 00:31, 12 June 2006 (UTC)

License?

The FAQ describes the license as "classic BSD", but it clearly isn't. It's a simple permissive license, more like the MIT license. It seems like it would be more clear to edit the article here to reflect this rather than calling it a BSD-style license. Can anyone point to any version of BSD ever released under this license? Or maybe the license text in the PostgreSQL FAQ is incorrect? --Johnsu01 17:49, 24 July 2006 (UTC)

Well, the Postgres developers certainly consider it to be "BSD licensed" (not "classic BSD" in the "4 clause BSD" sense). I think the license is functionally equivalent to the first two clauses of the original BSD license. Can we just call it a "BSD-style" license and leave it at that? Neilc 00:36, 25 July 2006 (UTC)

It is not the BSD License, nor is it "BSD-style". The closest equivalent is the MIT License. See this thread on license-review where Dave Page admits that he has no clue and that they assumed it was the BSD License because it came out of Berkeley... They were going to submit it for OSI approval as the "PostgreSQL License", but AFAICT they haven't. DES (talk) 10:52, 22 January 2010 (UTC)

Yes, I did submit it as the "PostgreSQL Licence", but OSI have yet to approve it. - Dave P.

When did you submit it? I haven't seen anything on the OSI lists. DES (talk) 11:31, 4 February 2010 (UTC)

http://www.postgresql.org/about/licence says it's released under a BSD-license. Changing this here on wikipedia, based on ones own personal opinion, is OR. Take this up with PostgreSQL, and get them to change it, and then, and only then, feel free to update the information on this wp-article. Jerazol (talk) 08:00, 3 February 2010 (UTC)

At the same time, it is fairly clear that this is a misnomer... even the term "MIT license" doesn't fit exactly. So one could just send a mail to their mailing list, include the relevant facts in it, and reference that right back in this article as a clarification :) --Joy [shallot] (talk) 14:59, 3 February 2010 (UTC)

It is not "personal opinion"; it is a matter of fact, which anyone can verify by comparing the licenses. I have discussed this with PostgreSQL people, and they agree that their license is not the BSD license. DES (talk) 11:31, 4 February 2010 (UTC)

This discussion is over. It's officially declared as the PostgreSQL licence. —Preceding unsigned comment added by Dark ixion (talk • contribs) 09:14, 26 February 2010 (UTC)

Prominent Users

Under prominent users Sony Online is listed as a PostgreSQL user which is technically incorrect. Sony Online are using EnterpriseDB (http://www.enterprisedb.com), which is based on PostgreSQL. Apropriate changes should be made.

How about we just remove it alltogether? It'll get filled up with cruft like this. — ceejayoz ^talk 21:33, 7 November 2006 (UTC)

I say we trim the list to notable entries that have solid references, which clearly establish that they are using it as a primary DBMS, and their usage is actually significant. E.g., products that support PostgreSQL as one alternative certainly don't belong here, nor do companies which might use PostgreSQL for an internal bug tracker. If that's too hard then we just drop it. -- intgr ^#%@! 10:33, 6 September 2007 (UTC)

Triggers on views

test=# create trigger bar BEFORE INSERT ON foo EXECUTE PROCEDURE eek();
ERROR: "foo" is not a table
84.160.218.201 18:58, 14 October 2006 (UTC)

Yeah, from an implementation point-of-view, attaching triggers to views doesn't make a lot of sense (triggers are fired by the executor, but by the time the query plan reaches the executor, references to views have already been replaced with the view's definition). Neilc 19:27, 14 October 2006 (UTC)

Views can have rules tho which can do some trigger like functionality. 69.31.174.216 (talk) 21:09, 8 January 2008 (UTC)

Reporting?

I don't see the word "report" mentioned. Are there reporting tools? The Postgres site mentions pgaccess but chasing that one ends up on a squatted domain. -- SEWilco (talk) 23:43, 13 December 2007 (UTC)

pgaccess is still available from sourceforge but the project area feels like a ghost town. I wonder where everyone's gone? Northernhenge (talk) 00:09, 15 January 2008 (UTC)

It is Free Software

Postgresql is not free software! Free software is software licensed under the GPL. The FSF invented the term "free software" and they are very clear the BSD style licenses do not count as free software. 69.156.22.178 (talk) —Preceding comment was added at 01:05, 10 April 2008 (UTC)

"Free software" is defined in terms of freedoms that it must provide; although FSF encourages the use of copyleft licenses, and GPL in particular, their definition definition of "free software" does not make it a requirement. See Free software#Definition and http://www.gnu.org/philosophy/free-sw.html. In particular:

"[...] But non-copylefted free software also exists. We believe there are important reasons why it is better to use copyleft, but if your program is non-copylefted free software, we can still use it." -- intgr [talk] 01:16, 10 April 2008 (UTC)

Boy am I embarrassed - you are of course right, and I was wrong. Thanks for educating me. 72.35.6.133 (talk)

Merge phpPgAdmin article to phpPgAdmin section

Make sense to me. Anyone else? +mt 04:31, 1 May 2008 (UTC)

• Oppose merge. phpPgAdmin is a short article, but it is about a separate tool, maintained by a separate group, than is PostgreSQL itself. In principle, I can see the article on phpPgAdmin being expanded. LotLE×talk 19:45, 1 May 2008 (UTC)

JOPS

What is a JOPS? Can anyone explain this? Google can't. 75.73.43.136 (talk) —Preceding comment was added at 22:11, 13 April 2008 (UTC)

First guess from Acronym Finder is "jAppServer Operations Per Second". —Preceding unsigned comment added by 114.134.161.9 (talk) 02:04, 2 May 2009 (UTC)

PL/LOLCODE

Should we really be including links to esoteric programming languages? I dont think this contributes much to the article and should be removed. --Chapium (talk) 04:30, 15 May 2009 (UTC)

I have no issues with it, and I find it kind of funny (RDBMS suffer from too much seriousness). It does demonstrate the unsurpassed procedural language extensions available for PG. +mt 15:42, 15 May 2009 (UTC)

DESC indexes

PostgreSQL is capable of scanning indexes backwards when needed; a separate index is never needed to support ORDER BY field DESC.

Every database system is capable of scanning indexes backwards when needed. In fact, this ability is a part of the core functionality of B-Tree indexes. Do we really need to mention it on the page? Abolen (talk) 22:26, 6 March 2010 (UTC)

Major releases

I was wondering about the "Major releases" table, it shows two "Date" columns. I guess the first one is the release date, but I'm unable to figure out the meaning of the second one (it looked like the end-of-support-dates at first, but this still doesn't make sense looking at the last few rows and the legend below). 188.22.161.97 (talk) 11:40, 26 October 2010 (UTC)

Is is clearer now? The second date is to be paired up with the latest release date. +mt 14:51, 26 October 2010 (UTC)

Multiple versions in template

Yes, it's a hack on {{Infobox software}}, but the template only supports one version. PostgreSQL has several current releases, and all are fully supported and widely used. +mt 23:05, 18 April 2011 (UTC)

I'm not agree. Do you see THE major open source project: Firefox? Or Ubuntu (operating system)...?--B3t (talk) 08:04, 19 April 2011 (UTC)

I'm with B3t. MySQL, Ingres (database), and Joomla are other example of a multi-generation package which only list the latest version in the infobox. --Simple Bob ^{a.k.a. The Spaminator} (Talk) 08:28, 19 April 2011 (UTC)

I don't see why examples in other articles is relevant to this discussion (although I've been thinking up a meta template solution for a while now). The discussion should be whether this article should show multiple current versions in the infobox? I think it is important to illustrate this at the top (granted it is also reiterated in the "Major releases" section). +mt 23:21, 19 April 2011 (UTC)

The examples are totally relevant. It shows that other software packages that also maintain releases across multiple generations do not have those generations shown in the infobox. That sets a precedent which this article should follow. --Simple Bob ^{a.k.a. The Spaminator} (Talk) 06:30, 20 April 2011 (UTC)

That's a bit of a logical fallacy, as it poses that the selected article examples are either somehow "correct" and/or have discussed this topic (i.e., one can easily reverse the argument as: "this article sets a precedent with which the other articles should follow"). The possible reality is that the other examples do not display their multiple current versions in the infobox as either the authors haven't thought about it or the authors have rejected the idea as the template(s) do not support this feature easily. (Oh, add Python (programming language) to the counter example set.) This topic should probably be discussed at a broader page (e.g. WP:PUMP); I'll post a link back here when I start it. +mt 19:58, 20 April 2011 (UTC)

I just asked at Wikipedia_talk:WikiProject_Software#Content_of_Infobox_software_-_how_many_software_releases_to_show?. --Simple Bob ^{a.k.a. The Spaminator} (Talk) 20:12, 20 April 2011 (UTC)

Who writes this?

Who are the contributors, and why do they contribute? The main page says there are a lot of contributors etc but there's little real detail to be found about who pays and who runs the bureaucracy. With all the MySQL hoopla, Stallman himself saying MySQL would go undeveloped if purely open-sourced, I'm sure I'm not the only one wondering what PostgreSQL's secret is. —Preceding unsigned comment added by Kestasjk (talk • contribs) 23:33, 10 November 2009 (UTC)

"about who pays and who runs the bureaucracy" — PostgreSQL is not a company, it's a community project. The project is ran by the PostgreSQL Core Team which consists of 7 people from 6 different companies. Major and minor contributors are also listed on that page, with many other companies that hire developers to work on PostgreSQL. -- intgr [talk] 11:42, 22 January 2010 (UTC)

"The project is ran ..." ?? That's scary ...210.22.142.82 (talk) 08:26, 2 June 2013 (UTC)

Article issues template

An anonymous editor has added an "issues" template to the article. I am copying the rationales here to hopefully get some discussion going:

• insufficient inline citations: Some sections are completely missing
• neutraility disputed: The features section is massive!
• written like advertisement: A lot of links to external projects. Too many. Also some paragraphs only about other companies (Proprietary derivatives and support - 2ndQuadrant for example)

I agree with some of this. The article has degraded into enormous lists, many of which are too detailed for an encyclopedia article (list creep) and aren't really covered by reliable independent sources (you shouldn't cite mailing list posts, blogs or documentation generally). External links to other projects should also be reduced to bare minimum (except useful sources of course).

I would slash the "contrib modules" section entirely. Substantial contrib modules like pg_upgrade, hstore, pg_trgm could be covered elsewhere in the article in context. Out-of-contrib procedure languages should be removed. The list of CPU architectures and operating systems, "Other features", "Add-ons" and "Upcoming features" should be mostly deleted and remaining covered in prose in more depth.

If anyone is worried about content being lost, these can be migrated to the PostgreSQL wiki.

Thoughts? -- intgr [talk] 19:21, 13 May 2013 (UTC)

Sounds fine for me 217.211.59.24 (talk) 10:17, 17 May 2013 (UTC)

I don't see how a large feature list makes the article non-neutral. David Skoll (talk) 01:32, 25 May 2013 (UTC)

The 'list of CPU architectures and operating systems' can actually be useful. Since I am a user of a non-mainstream operating system, finding out if a particular program can be made to work is a valuable bit of information. In a way, it's similar to saying, "Wheat is a common grain, it is found in six of the seven continents." The proof that PostgreSQL (in this case) is a widely-deployed application is worth including (imo). 210.22.142.82 (talk) 08:35, 2 June 2013 (UTC)

Hi just came to the article and was disappointed that the issues template is still on 5 months later. I am going to take it off.

RonaldDuncan (talk) 11:00, 7 September 2013 (UTC)

History and most important features first

I renamed section to "New features in 9.3" since no longer upcoming, and copied some features to it's rightful place. However I didn't add, "As of version 9.3" or "In version 9.3 and above" or such. It is useful information if you already have an older version (use the official documentation) but not so much if evaluating to start using PostgreSQL? Maybe if peole refrain from using the just released version but still, Wikipedia is not a changelog and should we really clutter the page with such stuff? I'm in no hurry to edit out this stuff, just not adding more. Isn't it official policy of Wikipedia to describe the current version? There should be a history section, does it need to be right after the lead (and mention all the older versions)? I'm thinking of moving it lower at least and more important feature up but forsee people not agreeing what is most important such as new feature (streaming replication). comp.arch (talk) 12:17, 1 October 2013 (UTC)

+1, I already prevented someone from creating such a section for upcoming 9.4 features. I think the 9.3 section should be removed as well, but didn't want to do it myself. There are just so many other places that cover the changes much better.

I'm less sure about removing the "Major releases" section, such an overview doesn't seem to exist anywhere else. But I agree that it conflicts with WP:CHANGELOG. -- intgr [talk] 14:43, 1 October 2013 (UTC)

The "Major releases" table was initially added to show one or more additions from each release that is interesting from a history perspective. The additions for newer releases (after the table was added) are much longer and excessively detailed, and I think they need to be scaled back so that they only take up one line of the row (listing at most 4 or 5ish features). Notable parts of the "New features in 9.3" section should just be merged into the "Features" section of the article, without any need to specify "as of version". However, I think some of the details in the "Features" section could be trimmed out, since that section is looking a too heavy. +mt 05:15, 2 October 2013 (UTC)

When was QUEL dropped?

Was just wandering. Went looking: this just confirms it was dropped.. comp.arch (talk) 16:44, 23 March 2014 (UTC)

Have a look at the date when that blog post was posted :-) Apart from that, I don't have the answer to your question. TommyG (talk) 08:37, 25 March 2014 (UTC)

That is partly why I posted this, but in all seriousness I wanted to know when it was dropped. You don't have to find it for me. But the article talks about it but doesn't mention when/why it was dropped (or reintroduced..:) As it "didn't make it" again into 9.1 maybe we should say someting about its disappearance in the past. I know that SQL is the standard now, just wandering if dropping QUEL was a "mistake". Haven't looked into it too much. Was it technically (in part) better? comp.arch (talk) 14:44, 25 March 2014 (UTC)

Trivia: "Canary Islands make Postgres default database"

"The Canaries are one of Spain's 17 autonomous communities". Not a whole country. [Has counies.] Any better example (bigger/"whole" country)?

https://joinup.ec.europa.eu/community/osor/news/canary-islands-make-postgres-default-database comp.arch (talk) 11:16, 4 April 2014 (UTC)

SSL vs TLS

From page: "Encrypted connections via SSL". Not sure how many use this (or connection outside if datacenter). From SSL page: "Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL)". Just wander is that a problem (see recent security issues). I believe PostgreSQL has not upgraded to TLS. Is it something they should to? comp.arch (talk) 21:54, 22 March 2014 (UTC)

Documentation mentions SSL (not TLS)[3] As all versions of SSL including latest SSL 3.0 are broken; is SSL in the documentation and configuration options assumed to be an "alias" for TLS (renaming them now to TLS would a good choose..).

Is SSL handled by Postgres directly or "outsourced" to a library (in all cases?; OpenSSL?). See Transport Layer Security. There have been fixes for SSL, but I understand both client and server need it and even then it's only a mitigation and SSL can't be fixed. Does Postgres for sure use TLS or can and then what versions. See also: [4][5][dba.stackexchange.com/questions/8580/force-postgresql-clients-to-use-ssl][6] comp.arch (talk) 12:33, 20 October 2014 (UTC)

Of course Postgres uses a library (OpenSSL), no one should reimplement TLS. According to a blog post, official PostgreSQL clients always use TLS 1.0 or later and they don't implement SSL 3 fallback, so they're not vulnerable to POODLE. -- intgr [talk] 13:46, 20 October 2014 (UTC)

SIMILAR TO

See Talk:SQL#SIMILAR TO. John Vandenberg ^(chat) 02:35, 6 October 2015 (UTC)

Is it correct to say "standard default database"?

The article says "PostgreSQL is its standard default database", and this phrase dates back to 12 November 2011. I checked all three references, but I couldn't figure out what this means, and English is not my native language. I guess it means that you can select your default database when you buy/install the software, and PostgreSQL happens to be the standard choice. Is that correct? --τις (talk) 00:49, 18 November 2015 (UTC)

It should probably be changed, especially if the sources don't use that phrase. -- intgr [talk] 08:09, 18 November 2015 (UTC)

It simply means that, in the standard setup, PostgreSQL is the default database. It comes preinstalled and ready-to-use. Any other database requires installation etc. A clearer phrase would be "On OS X, PostgreSQL has been the default database since Mac OS X 10.7 Lion Server..." I will make the change. Greenman (talk) 12:34, 18 November 2015 (UTC)

About indexes in PostgreSQL

This is clearly wrong to write about "two types of inverted indexes"

PostgreSQL includes built-in support for regular B-tree and hash indexes, and two types of inverted indexes: generalized search trees (GiST),generalized inverted indexes (GIN) and Space-Partitioned GiST (SP-GiST).<ref name="SP-GiST" />

It should be

PostgreSQL includes built-in support for regular B-tree and hash indexes, and four index access methods: generalized search trees (GiST),generalized inverted indexes (GIN), Space-Partitioned GiST (SP-GiST) <ref name="SP-GiST" /> and Block Range Indexes (BRIN).

Obartunov (talk) 06:31, 27 April 2016 (UTC)

Removed Release History

Removed release history, as WP::NOT a Changelog, and no other database pages have extensive release histories. The current version is displayed on the side. Any one have issues with this, and want to discuss? Would be interested in hearing arguments, but trying to bring all the database pages in line with the same sort of rules for each other following wikipedia guidelines q (talk) 03:53, 23 August 2016 (UTC)

I don't share the view that the release history constituted "exhaustive logs of software updates" (from WP:NOTCHANGELOG), and have restored the section again. This table briefly describes major releases, which are pretty common on Wikipedia (e.g. List of Ubuntu releases, Mac OS X 10.2, Adobe Photoshop version history, etc.). An alternative is to break the table into a series of paragraphs for the "History" section like "On July 1, 2009, PostgreSQL 8.4 was released that introduced windowing functions..." for each major release. The table also shows the other concurrent releases (since only one shown in the infobox). I'm happy to discuss this more, but deleting should be a last resort as the section has relevant history and version information not discussed elsewhere. +mt 03:03, 2 September 2016 (UTC)

Can anyone else chime in here? This is clearly an exhaustive history of software updates, going back to it's early release. It doesn't add anything to the article, or understanding. Deleting it is not a last resort, it is not appropriate for the article. If you want to break it out into a separate page with a link to it, that would make significantly more sense. q (talk) 23:00, 15 October 2016 (UTC)

Not it's not "clearly exhaustive"; I know a lot of details are missing, some very useful for those upgrading; sometimes there are disclaimers on what you need to do additionally when upgrading to a major version (not just for minor). I might draw there line there; even if it's helpful to the reader, who my be upgrading. I might go with trimming the log, to supported versions; but still what's the point them? At least part of the log should be in, helping people on deciding to update to another major version, or for people who might have outdated, preconceived notions, that e.g. updated-able VIEWs are not fully supported, and MATERIALIZED VIEWs not in yet. comp.arch (talk) 16:26, 16 October 2016 (UTC)

I understand there are details missing, that's true of anything and it a tautology. The point is, it is a change log. I'm not trying to be unreasonable, but it's an uncited, an unsourced summary of things that occurred in various releases. No other database pages include that level of detail. I think that as an explanation it may make sense, but at a log it doesn't belong. q (talk) 07:57, 17 October 2016 (UTC)

A document that best resembles a "change log" (besides the commit log) is the Release notes. For example, Release 9.6 was just under 8000 words. This was summarised into a Press Kit of approximately 650 words for each translation. On the table in this article, this information is further reduced to just 20 words. That's a ratio of 400 reduction from the change log, and no-one is advocating to expand this table (besides adding third party references, which is clearly the next step). However, as there is one major release per year, this table in its present form would expand one row per year. Splitting the history section off as a separate article may eventually need to be considered. +mt 08:58, 17 October 2016 (UTC)

It is my belief that the article is more understandable, and reasonable without the list of releases going back to .01. If others disagree, then that's a reasonable conclusion, but in my view it is not adding anything. q (talk) 17:18, 17 October 2016 (UTC)

The first release was 6.0 (according to PGDG), so this is certainly a reasonable reduction that I'll get to while sourcing 3rd party references in the table.+mt 18:36, 17 October 2016 (UTC)

You've readded it back. It is a clear violation of WP:NOT changelog, for a very good reason. It's just a list of data, and adds nothing to the understanding. It's not cited information from third party sources (or any sources). If you really feel strongly about it, make it a new page called the history of postgres. q (talk) 10:00, 16 October 2016 (UTC)

So, I was asked to take a look at this. In its current form, it's mostly unreferenced and unexplained, and pretty much just is a changelog. I think some items in there probably could add value to the article, but not really in the current form. As one example: "Changed copyright to a more liberal license." To what? From what? What was the significance of that? As it stands, that doesn't give the reader any real information at all, nor does it even cite a reference they could look to for further information. Same with "Optimization all round". Optimization of what? Why? What was the significance? That's why it's usually better to write stuff like this in a prose format than a table like that. A lot of the rest is highly technical terminology. I understand most of it since I've done a good deal of development and optimization on multiple databases, but articles should be written at the level of an interested amateur at most, not something that would only be understood by someone who's already a professional in the field. I think it would be best to rewrite that section in a prose format, and to highlight changes that reliable sources actually flagged as significant, with explanations of what they were and why they mattered from that reference material. But when something is challenged on sourcing grounds, it is inappropriate to reinsert it until and unless references are provided. Seraphimblade ^{Talk to me} 15:16, 16 October 2016 (UTC)

"is highly technical terminology", yes, I can go with changes, but for stuff, say [MATERIALIZED] VIEWs that are actually in the standards, I think it would be enough to link to those concepts. "actually flagged as significant", maybe, standard support seems automatically important to me. comp.arch (talk) 16:35, 16 October 2016 (UTC)

About the lead

I restored most of it; "technical content" part in almost original form.

Now; you may think some of it is redundant (not an argument; as lead should summarize; other DB articles seem way to short); with article, or relational database implies. You would be surprised.. SQL isn't implied, complex queries or not. I used to work with Informix; it (and others) have (had?) locking issues; MVCC is important; and only few databases support. ACID also is (and dirty reads a problem for some databases); noSQL often does without, on purpose. More could be said on ACID and maybe noSQL-type support in PostgreSQL (at least in non-lead). Feel free to propose changes, including the lead, or just change, but hopefully not delete all..

You would also think indexing is supported by relational; no! (yes, I think always for object-relational); relational can't be made fast, but I understood the SQL standards are silent on it (while all the databases support); PostgreSQL hovever has additional indexing methods, e.g. spacial, that I understood not widely supported, and while I know less on that, some index (and other functionality) not supported by others. comp.arch (talk) 14:07, 20 October 2016 (UTC)

I tend to follow the computer science style guide which uses 2 paragraphs for the lede. MVCC is important, but not in the lede. More than a few databases support MVCC, but that's fairly irrelevant to this discussion. I agree that ACID should be included in the lede. The article reads better with the deletion than including it, but I understand your dislike that I deleted the content. - My view is that the lede should be a fairly easy to understand summary of what a database is. Then much more technical content is elaborated on in the rest of the article. I've been a DBA and architect on many databases my life. Like you, I understand the complexity here, however I feel like the lede should not be written at that level. ACID, makes sense. MVCC, is much more technical.

Without the section in question, anyone can understand what the article is about. With it, requires special knowledge.

"My view is that the lede should be a fairly easy to understand summary of what a database is." No. Maybe you misspoke. Database system should say and does what A database is. Relational database management system, in the lead as RDBMS, what I relational database is additionally (etc. for "object-relational"; I didn't feel like spelling out relational again).

The lead should say what PostgreSQL is – in addition – to the minimum to what [object-]relational says. Then ACID, may be redundant, and referencial-integrity, even MySQL supports now. At the time, when I first put that in, MySQL was considered ok with not having that; arguably not a relational one then.. and it was a (and is) major competitor.

Wasn't aware of "the computer science style guide which uses 2 paragraphs for the lede" (where is that?); and still feel MVCC is important, I believe no other open source database has that, at least not MySQL. And I only knew of Oracle as a proprietary one; could have changed.. comp.arch (talk) 14:35, 21 October 2016 (UTC)

"PostgreSQL implements the majority of the core SQL:2011 standard,[13][14] is ACID-compliant and transactional (including most DDL statements) avoiding locking issues using multiversion concurrency control (MVCC), provides immunity to dirty reads and full serializability; handles complex SQL queries using many indexing methods that are not available in other databases; has updateable views and materialized views, triggers, foreign keys; supports functions and stored procedures, and other expandability,[15] and has a large number of extensions written by third parties. Replication of the database for availability and scalability is possible, to a cluster of computers"

Now, that's not the only reasons I removed it. We have "majority of the core", "most DDL statements". "many indexing methods".. "that are not available in other databases". "large number of extensions". - That is extremely sloppy throughout, let alone the not available in other databases, is unsourced, and unverifiable.

In my view, this is a clear, reasonable deletion that makes sense. Removing it, the lede is very easy to read, and understand. With it, it's difficult, unsourced, and a list of features at times using a lot of unquantifiable words. q (talk) 10:47, 21 October 2016 (UTC)

I have edited it to keep some level of content there, while removing the unsourced list of features that are fuzzy "many" "most of" etc. q (talk) 10:53, 21 October 2016 (UTC)

SQL:2008 and other was added here (not by me!) in response to lead to short (then with "including all DDL statements"; I can look into why (I) changed to "most"; I guess because of MERGE, that may be now in..). I just modified to SQL:2011. [Later "lead too short" (never by me), was again added.] Nobody support all of that standard I'm sure (or probably never has any of them). It includes e.g. "Embedded MUMPS"[7] Getting the "majority" is I think pretty good.. People can see exactly what is, and isn't supported from the sources.

"many [indexing methods]" is true; more than two, makes many, then ok for WP:V. Some databases have only B-trees, article lists at least six; and then partial indexes etc.

I believe, from memory, that the lead actually doesn't need any sources, the manin text does, and the lead should summarize. comp.arch (talk) 16:01, 21 October 2016 (UTC)

Section about intra query parallelism is outdated

The article says "A single database session (connection) cannot utilize more than one CPU.", but that's not true since the release of http://www.postgresql.org/docs/devel/static/release-9-6.html ("Parallel execution of sequential scans, joins and aggregates"). — Preceding unsigned comment added by 172.56.6.53 (talk) 19:23, 27 May 2017 (UTC)

History ends in 1996?

I'm sure a few notable things have happened in the last 20 years; it doesn't have to be a blow-by-blow version history table, but a few of the major technical and organizational highlights would be appreciated. Particularly the point when OSX started using pgsql. SilverbackNet ^talk 18:51, 4 July 2018 (UTC)

Reliability section

User:Intgr, Could you explain what is the problem with the Reliability? Could you propose any changes to fix it? — Preceding unsigned comment added by 176.82.39.172 (talk) 14:12, 7 May 2018 (UTC)

(Discussing this addition) My problem with the added content is that it lacks any sort of nuance that the source brings up.

It makes it sounds like PostgreSQL is squarely to blame, whereas the actual problem is that PG's expectations about error reporting do not match with what the OS is able to deliver. Given that other applications besides PG are also affected and Linux developers are making efforts to fix these issues, suggests to me that this is an issue in operating systems. Direct I/O is one alternative API that has reliable error reporting, but it's also possible to fix fsync, it seems.

Secondly, it's impossible to not lose data when writes to storage fail (redundancy is provided by other layers, not PG itself). The issue is that the data loss goes unreported to applications and PG does not know to abort transactions, leading to a corrupted state. -- intgr [talk] 15:44, 7 May 2018 (UTC)

If you read the article, direct IO fixes this issue as every write failure gets reported right away and the database can either try to write to other place or report the error about the write failure. The main problem is that current write failures go unnoticed. Please, see the new content I added. — Preceding unsigned comment added by 2.142.225.90 (talk) 17:33, 7 May 2018 (UTC)

The section is clearly problematic. 1) it is a random bug, every piece of software has bugs and we are not going to list them all. Listing that one is undue 2) the bug itself is actually a Linux bug, not PostgreSQL so it is off topic 3) the source cited is a primary source (a discussion on a mailing list) so also note reliable 4) on top of everything else, that bug (per source cited) was fixed just a few days after it was reported. So it there ever was a reliability issue, it is no longer true. That fact was pointed out to the IP user trying to impose that change but they chose to revert anyway. Still assuming good faith, but we are getting into the territory of the IP willfully entering factual false information. I will remove that section again. We would need way better sources offering context to add that section again. --McSly (talk) 20:34, 9 December 2018 (UTC)

1) We will not list all the bugs, but the problematic ones that have independent sources, 2) PostgreSQL could be fixed by using direct writing to prevent this issue, 3) Linux Weekly News is a reliable source, not a mailing list, 4) could you, please, provide a reliable source that shows that the issue is fixed? Please, do not remove content unilaterally until the discussion is settled. Oimpeace (talk) 12:12, 22 December 2018 (UTC)

Regarding your last statement - please read WP:BRD. Restoration of the deleted text is currently under discussion, and the onus is on those who support its inclusion to prove it belongs on the page, not on those who removed it to prove it doesn't belong. Mindmatrix 13:14, 23 December 2018 (UTC)

HTML formatting of this article

In this edit, Beland (talk · contribs) asks for help sorting out some HTML formatting but I can't see where the problems are. Are there any specific sections that need attention? --Northernhenge (talk) 18:52, 17 March 2019 (UTC)

Sorry for the confusion; when I'm adding this template these days, I include a parameter which specifies which tags need to be cleaned up. In this case, the database scan found <tt> tags, which Aveekbh has already helpfully cleaned up. So, I've removed the cleanup template. Thanks to you both for your help; there are tens of thousands of articles to clean up, and I couldn't do it all by myself! -- Beland (talk) 19:46, 17 March 2019 (UTC)

No problem, I was just looking up PostgreSQL, and chanced upon the template. Aveek (talk) 13:59, 18 March 2019 (UTC)

Disputed edit to the introduction

This edit by 68.58.56.64 (talk · contribs) is a partial revert of some work done by Jerryobject (talk · contribs). The edit summary for the partial revert described the original edit as "unconstructive". The edit looked ok to me. Do other editors think it was unconstructive or ok? --Northernhenge (talk) 21:22, 20 May 2019 (UTC)

The edit in question serves many purposes.

1. The earlier part is mostly to clarify the WP:LEAD section for topic novices, e.g., write for a reader, maybe a high school student, a new journalist or company officer, who has heard vaguely that, for their future in the computer industry, it is important to know about something called PostgreSQL.

2. The editor at IP 68.58.56.64 is also the one who, in a revision on 18:53 18 May 2019, inserted the licensing status (open source), a legal issue, even before a reader can learn that the article topic involves software. Licensing status is very important, which is why I moved it from the end of paragraph 2 to the end of paragraph 1, but it is less important than a clear orderly description of what an article is about. Wikipedia is used by many people who have little or no idea what open source might refer to. To be better understood, it benefits from a context.

3. The WP:ABBReviation ACID was undefined.

4. Some links needed updating, or were needless WP:NOPIPEs.

I can go on, and on, but I covered most of the relevant points in my linked edit notes. If you wish further clarification, let me know.

Thank you. --Jerryobject (talk) 06:41, 21 May 2019 (UTC)

I have made a series of specific fixes to problems that were introduced. According to WP:LEAD, the lead "should stand on its own as a concise overview of the article's topic." It does not need to be pedantic or stylistically obtuse. 68.58.56.64 (talk) 17:36, 21 May 2019 (UTC)

Also note that the articles for MySQL and MariaDB mention the licensing in the first sentence. This is an important issue for databases in particular, since competing commercial systems are both closed-source and very expensive. 68.58.56.64 (talk) 17:45, 21 May 2019 (UTC)