
PostgreSQL: the good, the bad, and the ugly - pykello
http://lwn.net/SubscriberLink/645020/e1ba36cff8248df0/
======
dimino
> The experience of Firefox and Chrome is that long release cycles actually
> decrease quality, precisely because of the dynamic on display here: long
> release cycles create huge pressure to land under-done features just before
> a deadline. With date-driven short release cycles, if you're not confident
> in your feature you'll be happy to just slip it to the next release. It
> greatly reduces stress on developers in general.

This comment really resonates with me, and wasn't something I thought of --
the pressure to deliver when your release cycle is so infrequent is something
I hadn't noticed before but once mentioned, realize it's absolutely true.

~~~
mook
Unfortunately, it seems like short release cycles can also lead to buggier
released; after all, who cares, it'll all be fixed in eight weeks or whatever,
right? It's not like people will be using the broken thing for a year.

Of course, the next release will then have a _different_ minor bug. Then the
pattern repeats.

~~~
organsnyder
I don't think that long release cycles are the solution for this, though—major
x.0 releases are well-known for often being buggy themselves, after all. I
think that buggy releases speak more to problems with general project
management and priorities than to the release schedule used.

------
pjungwir
I lurk (mostly) on the Postgres general mailing list (not the hacker list),
and I recognize a lot of the names in that article. I've got to say that the
helpfulness and civility of the folks there is amazing. I'm sorry to hear
there are tensions around the release process. I'm glad the article expressed
that in spite of those tensions, there is basically good will. That fits my
impression of the community. I don't write much C, but I've got a few features
I'd love to find time to contribute. I'd be honored to be a part of that
project.

------
nwenzel
Nothing quite like seeing the sausage get made. But, the open discussion,
while perhaps unnerving, is certainly preferred (IMHO) to a closed source
development process happening behind closed doors. A bit of chaos is the price
to pay for the open process.

Command-and-control does have some advantages. And maybe as Postgres grows,
the advantages related to a more orderly process become more visible. (For the
record, I think Postgres is a fantastic RDBMS + JSON store)

~~~
arithma
Placing JSON store at equal footing with RDBMS is a little bit loaded.

------
jilted
I think the PostgreSQL Development Group does a great job overall. If they
indeed have a reputation of being hard to work with, all the better in my
opinion if it means guarding the integrity of the Project.

~~~
pyre
> if it means guarding the integrity of the Project

That's a big "if." There are many projects that have been controlled by "hard
to work with" developers, and it's not always a good thing. Even if the
project doesn't suffer significantly from it, that doesn't mean it's _helping_
the project either.

That may not be the case here, but just as a general statement, you can't
chalk up "hard to work with" as equating to "focused on quality" and/or "good
for the project."

~~~
boomzilla
It's open source with a very liberal license. If someone is too difficult to
work with, the rest will just fork and move on with life. Do you think the
fact that people stick around, and have a respectful discussions means that
the guys are not too hard to work with, and the values they provide outweigh
the challenges of working with them?

~~~
pyre
My comment was more on the general "being hard to work with is a sign of
skill" idea that pervades the industry.

> If someone is too difficult to work with, the rest will just fork and move
> on with life.

This is a gross simplification.

------
_jmar777
A prime example of handjamming inconsequential happenings into a good/bad/ugly
blogpost format. If this is what counts as "the ugly", they're doing pretty
dang good.

------
ExpiredLink
... for PostgreSQL developers, not users.

~~~
nwenzel
But it is a look at the process that eventually impacts users. It explains why
upset has taken so long. A bit of chaos and a bit of politics.

~~~
ProblemFactory
I don't think upsert has taken so long because of the community and processes,
but because the Postgresql team has high requirements for it:
[http://www.depesz.com/2012/06/10/why-is-upsert-so-
complicate...](http://www.depesz.com/2012/06/10/why-is-upsert-so-complicated/)

For example, upsert that is worth releasing should:

* Work with all unique indexes that may exist on a table, not only a primary key,

* Be correct even at highly concurrent writes, at any isolation level from Read Uncommitted to Serializable,

* Be fast even at highly concurrent writes, so no table locks, locks may not be held for more than an instant, and no re-running the entire transaction in a loop,

* Never throw an "another transaction modified data" exception at Read Committed isolation level, it should always correctly succeed as an insert or update even if another parallel transaction inserted or deleted the matching row.

I'm not familiar much with the other database engines, but my impression has
been that their upsert or SQL merge do not provide all of these.

------
mr_gaga
Article is obviously for PostgreSQL developers BUT my gripe as a user (coming
from MySQL).....the hardest part about transitioning from MySQL to PostgreSQL
isn't PostgreSQL itself but transitioning from phpMyAdmin to phpPgAdmin.
phpPgAdmin seems like it's trying to make my life difficult.

~~~
jperras
Stop using web-based admin tools, and learn how to use the CLI interface.

I mean this in the best, nicest possible way; we've all been there. But
learning how to use the CLI will pay dividends in the short _and_ long run.

~~~
philh
I'm skeptical that the CLI can do everything I'd want, but here goes. Is it as
easy to use as phpMyAdmin when I want to:

\- Change the sort order? (PMA: Click a column. CLI: Edit your query to add an
ORDER BY clause?)

\- Edit a value? (PMA: Double-click and edit. CLI: Check the primary key and
write an UPDATE query? Hope not to make a typo when writing the key.)

\- Look up the row corresponding to a foreign key? (PMA: click it. CLI: write
a SELECT query?)

\- View the extreme values of a result set? I.e. I run a query which returns
200 results, and I want to look at the first few and the last few. (PMA: home
and end. CLI: scroll?)

~~~
baldfat
All of those can be done in the CLI and quickly.

CLI has a learning curve but what many will say is that we are SO GLAD we
learned to not use our mouse to work with our data base and especially our SQL
code.

The reason why I like using CLI is I can use GIT or any version control and
make sure I have a clear history of my SQL commands and everything I did.

TL:DR Database Vendor with a Windows Server product screw with the logs and
put the blame on me. I had a version control of all our history of CLI
commands. Vendor employee or manager changed our log files externally. We won
big court case (Before trial of course). Wouldn't have happened if I used the
GUI tools.

Long story short. The vendor at the library I want was 100% evil. I asked by
phone about two things. I emailed the engineer after the phone call for the
two questions. BOOM I lost one month of work unless my backups work. Boom I
lost half a day of work for 2 librarians. Vendor tells my boss and my school
it will cost us $5,000 due to my mistake for them to fix something (Took them
15 minutes work on the phone due to their error).

My boss and college have a good relationship with me and we go on a conference
call. Vendor tells a very convincing story and logs how I screwed up. They
don't have records of my phone call and have 100% confidence that their
employee would never okay both those things. I call them on the table. I have
the email with the answers that the engineer gave me. BOOM their Engineer VP
jumps in and says see if you did what he told you nothing bad would have
happened and our logs show ... I than email my version controlled CLI commands
for the past 6 months and show my commands that I did that day and that if the
logs on their end our different they have a serious problem internally.

Long story short we won the court case and we got over hundreds of thousands
of dollars back from that vendor.

~~~
philh
> All of those can be done in the CLI and quickly.

I'd love to know how.

~~~
baldfat
I would try: First One Hour: [https://www.khanacademy.org/computing/hour-of-
code/hour-of-s...](https://www.khanacademy.org/computing/hour-of-code/hour-of-
sql/v/welcome-to-sql)

Also these two seem decent:
[http://sol.gfxile.net/galaxql.html](http://sol.gfxile.net/galaxql.html)

[http://sql.learncodethehardway.org/](http://sql.learncodethehardway.org/)

The Hard Way has semi-decient issues.

I would say SQL is easy to learn and would take only a few days to get the
basics and than just learn as you come to stuff your missing. SQL is a very
tiny language.

~~~
philh
So, when you read these parts of my post:

> Edit your query to add an ORDER BY clause?

> Check the primary key and write an UPDATE query? Hope not to make a typo
> when writing the key.

> write a SELECT query?

did you think that I was saying: "I think this is how I would do it in SQL, if
only I knew SQL. Won't you please point me to somewhere I can learn SQL so
that all my problems will be solved"?

Because what I was going for was: "here is how I would do it in the CLI, but I
much prefer how I would do it in PMA. Please tell me if there's a better way
to do it in the CLI". I know SQL, I thought it was obvious that I knew SQL,
and pointing me towards SQL tutorials is super unhelpful.

~~~
baldfat
Go to Stack Overflow. Yes the reason why no one gave you your SQL code is we
know that the GUI is just making SQL code for you. Sorry we probably have the
mindset of we pointed you to the answer and we are not going to give you
specific answer to your questions.

I googled searched by copy and paste your question for 5 seconds for each
question:

> Edit your query to add an ORDER BY clause?
> [http://www.techonthenet.com/sql/order_by.php](http://www.techonthenet.com/sql/order_by.php)

> Check the primary key and write an UPDATE query?
> [http://stackoverflow.com/questions/3930338/sql-server-get-
> ta...](http://stackoverflow.com/questions/3930338/sql-server-get-table-
> primary-key-using-sql-query)

> write a SELECT query
> [http://www.w3schools.com/sql/sql_select.asp](http://www.w3schools.com/sql/sql_select.asp)

I think your issue is you are biased against CLI and think you get more
benefit from a GUI. We can convince you what is best for you. We are just
saying everything you pointed out is easily done in CLI with SQL commands. We
believe everyone who works with databases should use CLI for a number of
benefits because of our own experience.

~~~
philh
...what part of

> I know SQL, I thought it was obvious that I knew SQL, and pointing me
> towards SQL tutorials is super unhelpful.

makes you think that I just need _really basic_ SQL tutorials?

I get the impression that you're glancing at my posts, picking out a few
words, making up a question that someone else might have asked using those
words, and answering that question instead of the one I'm actually asking.

This is incredibly frustrating for me. As such, I decline to continue this
conversation.

~~~
baldfat
No I am being super Ironic. You are listing EASY to do SQL commands as things
that you don't know how to do. You than ask use to show you.

What is your question besides show me how to do 1, 2, 3?

------
slashnull
If it starts to suck like MySQL, will it become popular like MySQL?

I think that'd be a fair tradeoff.

