Live data from Hacker News

PostgreSQL Exercises

pgexercises.com

11–20 of 47 posts

Re: PostgreSQL Exercises

#14
post #4

Very impressive! Works well, nice UI, informative. After doing a couple exercises what I don't like is the naming convention. Something like "montlymaintenance" or "recommendedby" are just hard to read and type and I'd much rather use snake-case and/or shorter names. Eg. "monthly_maintenance" or "maintenance_per_month" or just "maintenance" if it's explicit enough that it's always per month. Also to me using shorthan…

Author here - thanks a lot for the feedback, it's appreciated.

You're right on the naming convention, it's very haphazard. I'll raise an issue on Github to revisit that - although it may take me quite a while to get to it as I have a two week old to look after right now :-).

Re: PostgreSQL Exercises

#15
post #2

Great idea, does what it should and can be extended to cover a lot more. Keep up the great work. First time looking at it I thought I was on a official Ubuntu site, what a font and color can do to a branding is fascinating.

Well, it is using the Ubuntu font! https://pgexercises.com/css/site.css

Yeah, I have zero design sense and just went with the defaults of a bootswatch theme that I liked :-)

Re: PostgreSQL Exercises

#16
post #2

Great idea, does what it should and can be extended to cover a lot more. Keep up the great work. First time looking at it I thought I was on a official Ubuntu site, what a font and color can do to a branding is fascinating.

Author here: out of curiosity, what would be your priorities for future exercises? Right now my list looks roughly like:

    - DDL
    - Advanced datatypes (JSON, arrays, etc)
    - GIS
This order is partly informed by the current support of the site: adding DDL exercises is a relatively minor bit of technical work, and then it's just writing. Everything else involves schema changes (or, possibly, a second database).

Re: PostgreSQL Exercises

#18

Zipcode is an integer? What about zips in New Jersey?

grins for that I'll have to say that I'm from the UK and that situating the exercises in the US was probably an error :-)

As a general rule of thumb, if something isn't used for calculations, it probably shouldn't be a number.

Re: PostgreSQL Exercises

#19
This seems as good of place as any to ask novice-level questions about PostgreSQL. I teach students SQLite and one of the most massive pain points in transitioning to PgSQL is how the latter, in the `WHERE` clause, fails to recognize aliases in the `SELECT` clause, e.g.

   SELECT UPPER(name) AS bigname
   FROM people
   WHERE bigname = 'JOE';
https://stackoverflow.com/questions/38040631/postgresql-does...

Apparently this is the SQL standard, which PgSQL seems to do a better job of following than SQLite, but I'm at a loss to understand why this computation is particularly problematic for PgSQL (or any variant) to adopt? Unlike other SQL standard rules that PgSQL follows that SQLite/MySQL doesn't (such as forbidding the selection of column names that aren't being GROUPed by in a GROUP BY clause), this strictness seems to be all inconvenience.

Re: PostgreSQL Exercises

#20

Earlier quoted context omitted.

grins for that I'll have to say that I'm from the UK and that situating the exercises in the US was probably an error :-)

As a general rule of thumb, if something isn't used for calculations, it probably shouldn't be a number.

That wouldn't generally be my approach. In my view if something is a number it should be typed as such.

That said, I recognise that there are pros and cons to this approach similar to those in strongly vs weakly typed PLs. My personal preference is for a strong schema.

Post reply on HN