Prague Postgresql Meetup #7

We are excited to announce our October meetup! The Seventh event of 2026 will take place on Wednesday, October 30th at 17:30 at Dataddo (Pod Dráhou 1637/6 (PORT7, building E3 - Dataddo offices 7th floor).

Lightning talks Submissions => [email protected]

Agenda:
17:30 Doors open
17:45 - 18:00 Dataddo - Host Introductory talk
18:00 - 18:30 What is Null? by Vik Fearing
18:30 - 18:45 Coffee Break
18:45 - 19:00 Lightning Talks
19:00 - 19:30 TBD
19:30 - 20:30 Networking
20:30 End of event

Speakers:
Vik Fearing is a Major Contributor to PostgreSQL and an official editor of the SQL standard, which he has helped write as a member of the ISO/IEC SQL committee (WG3) since 2022. He has been part of the PostgreSQL community since 2008 and lives in France.

Within the community, he is the founder and co-organizer of pgDay Paris, an inaugural member of the PostgreSQL Code of Conduct Committee, a moderator of several PostgreSQL mailing lists, an IRC operator for #postgresql and #postgresql-fr, and part of the team behind the @PostgreSQL account. He speaks at conferences around the world.

TBD

Talks details :
What is NULL? by Vik Fearing
"NULL" is a single token in SQL with at least six distinct meanings, and the standard is conspicuously quiet about which one you're getting at any given site. A NULL produced by an outer join doesn't mean the same thing as a NULL in an unpopulated column, which doesn't mean the same thing as the NULL SUM returns over an empty set, which doesn't mean the same thing as the NULL a ROLLUP super-aggregate writes into a grouping column. We call it "three-valued logic" as if that were the design. It isn't. The design is that we built one escape hatch and then stuffed everything we couldn't model into it.

This talk is the inventory I wish someone had handed me thirty years ago. I'll walk through every place SQL produces or accepts a NULL, what it actually means there, what the standard says about it (and where it declines to say anything), and what Postgres actually does at each of those sites. Postgres gets most of this right, which is interesting in itself, because "right" here means picking one reading of an ambiguous spec and living with the consequences. I'll point at the places where the consequences bite. I'll also detour through a few notable sins committed elsewhere, Oracle's insistence that the empty string is NULL chief among them, because the contrast sharpens what Postgres chose not to do.

If you've ever written x NOT IN (SELECT y FROM t), watched it return zero rows, and spent the rest of the afternoon working out why, this is the talk for you.

TBD

Looking forward to meeting you all again!