Postgre SQL is admittedly very wrong, however its also perhaps one of the biggest mistakes the project made early on (admitted by various community members).
I'll work to call out the two correct ones, and call out the confusion of the other separately.
It's wrong, but probably unavoidable. Attaching a spoken acronym to the end of a pronounced name is just so bizarre (has anyone else ever done that?) that people will simply skip it.
I've heard people say "post-gre", and like a new English speaker saying "We goed to the park", this overgeneralization isn't at all surprising. In computers, acronyms after names are very common, and it's typically harmless to omit them, e.g., saying "Windows XP" as "Windows" is more generic but not wrong.
I've never heard anybody ever say "post-gres-que-ell". ("Postgres" is correct, unambiguous, and sounds better. Why would I keep going and make it twice as many syllables?) They're trying to fight against the natural process of linguistic clipping with a FAQ!
I love Postgres as a database but I really wish they'd just drop that weird spelling. I don't think it's helping them at all these days.
> I've never heard anybody ever say "post-gres-que-ell".
I frequently, but not exclusively, say it like that. You knew someone would show up to say this. I admit I get weird looks. My coworkers all call it "Postgres."
I think you're right, but I also think if that's the best thing we have to complain about we have it pretty good.
I have this on my desk right now - it's been extremely helpful in scaling a large database and I'd recommend it to those who don't have any experience with indexing and partitioning as well (it explains them quite clearly). It goes into lots of system settings for tuning as well.
A primary key is the same thing as a unique index (any index which enforces unique entries) + a not null constraint.
It might make a difference in the heuristic for finding functional dependencies for group by though. This feature was introduced in 9.1 and allows one to not always have to list all columns in the GROUP BY clause.
13 comments
[ 2.9 ms ] story [ 37.8 ms ] threadI'll work to call out the two correct ones, and call out the confusion of the other separately.
I've heard people say "post-gre", and like a new English speaker saying "We goed to the park", this overgeneralization isn't at all surprising. In computers, acronyms after names are very common, and it's typically harmless to omit them, e.g., saying "Windows XP" as "Windows" is more generic but not wrong.
I've never heard anybody ever say "post-gres-que-ell". ("Postgres" is correct, unambiguous, and sounds better. Why would I keep going and make it twice as many syllables?) They're trying to fight against the natural process of linguistic clipping with a FAQ!
I love Postgres as a database but I really wish they'd just drop that weird spelling. I don't think it's helping them at all these days.
I frequently, but not exclusively, say it like that. You knew someone would show up to say this. I admit I get weird looks. My coworkers all call it "Postgres."
I think you're right, but I also think if that's the best thing we have to complain about we have it pretty good.
This directly contradicts with what the PostgreSQL documentation says.
> Adding a primary key will automatically create a unique btree index on the column or group of columns used in the primary key. (http://www.postgresql.org/docs/9.1/interactive/ddl-constrain...)
Is there a fundamental difference to the default pkey index versus an explicitly created index?
postgresql doesn't automatically create indexes for foreign keys.
> Is there a fundamental difference to the default pkey index versus an explicitly created index?
i don't know of any in practice.
I believe the difference would be on the constraint. A primary key is intended to be unique, where as an index does not alway carry that constraint.
It might make a difference in the heuristic for finding functional dependencies for group by though. This feature was introduced in 9.1 and allows one to not always have to list all columns in the GROUP BY clause.
SELECT RANDOM(GUIDE) FROM DATABASES WHERE DATABASE_NAME = 'POSTGRES'; ?!
The original article, thankfully, says nothing about being "curated".