CLAIRE: 00:00:00
Welcome to Talking Postgres. In this episode, we explore the human side of Postgres, databases, and open source. I want to say thank you to the team at Microsoft for sponsoring the community conversation about Postgres, and I'm your host, Claire Giordano. And I am so excited to introduce Daniel Gustafsson to you. He is a Postgres major contributor and committer. He's been involved with the Postgres project since 2014, co-founder of the annual Nordic PGDay event. And between 2014 and 2023, so about a year ago, he was a very frequent conference organizer. Events that come to mind are PGConf.dev and PGConf EU, and of course, Nordic PGDay. Daniel is based in Sweden, and he works at Microsoft on the Postgres contributor team, and recently stepped into an engineering management role too. And prior to working at Microsoft, Daniel worked with Greenplum for many years. Welcome.
DANIEL: 00:01:02
Thank you. Thanks for having me.
CLAIRE: 00:01:04
I'm so happy that you said yes. And the topic for today is "How I got started as a developer and in Postgres", where the "I" in that statement is, of course, you, Daniel. It's not about me. I'm privileged. I get to work with you, as do others in the Postgres world. And so I know parts of this, but I have a whole list of questions, and I don't think I know all the answers yet. So I'm excited to learn more about your background too. And I think I want to go in the way back machine and start with, when did you first get into computing?
DANIEL: 00:01:40
That's a good question. I don't really remember not having a computer at home, even though I was born in the '70s. So my dad started working in computers very early on, way back when there was only two computers in all of Sweden, like big hulking giants. By the time I was born, he was working at Datasaab, who was making mostly, like, airline-controlled computers and stuff. So my earliest memories is of a giant box, steel box, like a one meter squared, that was sitting in our study, which was a Datasaab M10, which is probably a computer that no one has ever heard of.
CLAIRE: 00:02:24
Can you say that again?
DANIEL: 00:02:26
It's a Datasaab, or Datasaab M10. It was a data entry terminal. Basically, it was a data entry terminal for clerks who would type in data, essentially. And it was discontinued. It was an EOL machine, even when I was five, six years old, which is what I remember it from. And the people working there, like the engineers working there, got to basically take the rubbish home. So what they did was homebrew, make their own, basically write their own operating system for it to have at home computers. And that's my earliest memory of sitting in front of a computer and working on a computer, this giant box with an orange fluorescent screen.
CLAIRE: 00:03:16
Now, when you say it's your earliest memory, do you think you were two?
DANIEL: 00:03:20
No, it was probably about five, five-ish, I think, four or five.
CLAIRE: 00:03:25
Okay.
DANIEL: 00:03:26
Roughly around that time. And then he just sort of progressed from there, because he was working building computers at the time, like physically building them and writing the operating systems for them. So we had a wide variety of machines home, which is not really the typical machines of the age, because the typical machines back then would be the Atari and Commodore. Those were the home computers at the time. But obviously, since he was working for business computer-wise, we had those machines at home. So they were all sort of like the Swedish-built machines. They would be called ABC 80, which is the really early one that I remember, and then ABC 800, Facit DTC. So these are basically machines that few people have ever heard of, I guess. But these are the ones that I remember starting out, and those are the ones that I remember sitting on my desk in my room when I was like seven or something. So that's where I got started. I don't remember not having a computer in front of me, essentially.
CLAIRE: 00:04:35
So when do you think you wrote your first program? When you were seven, when you had that ABC 80 sitting in your room?
DANIEL: 00:04:44
Yeah, I've been trying to remember that. Back when I was six, seven years old, I definitely was typing in games from those giant books of basic listing games that you could buy. I know my dad had a couple of those. So you would type in these pages and pages of code and hope that you didn't make a mistake halfway through, and then you'd get a game to play at the end. And I remember that sort of triggering an interest in, maybe I can do something on my own. So I was probably around seven or eight when dad taught me some early BASIC programming on one of those machines. But it wasn't really serious because, I mean, I was pretty young and had a whole stack of games at home to play. So it wasn't really that serious until probably around when I was 12 or so, 10, 11, 12, around that time, when I was more getting into programming and sort of like stopped playing games mostly and got more interested in actually making them myself or making programs.
CLAIRE: 00:06:00
OK. So let's say you're 12 years old. Are computers and software and programming, was that just something you worked on at home when it started to get more serious? Or was there also a computer at school, and was that something that was relevant to any of the teachers?
DANIEL: 00:06:20
So we actually had a computer lab at school probably around that time. It was in even another Swedish invention called the Esselte Compis, which is basically it's a Esselte "Friend", which was a school computer made in Sweden, which is absolutely dreadful. It's a classic one for sort of failed Swedish computer attempts. But I never actually did much there, because since I had all these machines at home and I had access to them at home, I didn't need to take that as an extra curriculum, because that was like an opt-in thing you could do at school. So that was never really a thing that I did, because I had it at home. But rather I did it, yeah, all on my own at home.
CLAIRE: 00:07:09
OK. So you definitely had an advantage over people whose parents had other types of professions that had nothing to do with computers. You got this early, early exposure to it. Let's fast forward a little bit. When did you first get paid to do any development work? Were you in high school? Was it after schooling? What's your first developer job?
DANIEL: 00:07:38
My first developer job was much later than that. My first job was when it came to computers was fixing them, building computers, repairing them. Because my dad then progressed into a wholesale business. And so I was working part-time for him, basically repairing motherboards and monitors and things. But my first job actually being paid to write programs was in the late '90s, when I left university and after my military service. It was sort of like the dot-com boom was really picking up steam. There was a lot of money involved. The university didn't seem that exciting all of a sudden when there was this other thing going on. So I was actually hired as a network engineer at the time, because there was a big push in the graphics arts industry to basically move from old novel networks into Ethernet and Windows NT and those environments. So that's what I was hired for. But it very quickly moved into, because basically when my boss realized that I could program and sort of make software for the company, it pretty quickly shifted into basically a full-time writing software job. So it was probably about '99, I think. And I was basically, so at the time, this was the graphics arts industry, and they were at the time shifting from printing off of giant plates that was developed in a photographic process into basically taking a PDF and printing it onto the plate and then having that in the printing press. But it's a very big shift from going from a PDF and straight into the printing press versus going via chemical processes and wet baths and stuff. So there was a lot of automation software, a lot of integration software that had to be written to make these PDF workflows work. And we did very well in that space, because there was a lot of work, and there was basically no one else doing it.
CLAIRE: 00:10:02
So when you say "we," who's "we"?
DANIEL: 00:10:05
It was a very small company, like a five-person company that no one's ever heard of. But we worked with some very big customers and did surprisingly cool stuff for being this tiny company that no one knew about.
CLAIRE: 00:10:23
So then you'd left university, you had this job, you're in the graphic arts industry, they're doing a migration, a shift. I'm assuming databases were not part of your portfolio or your expertise yet, am I right? Or did I miss a step?
DANIEL: 00:10:43
No, definitely not. So most of the stuff that I did did not need a database at all. But as we progressed and as we made more and more advanced software, we came to the point, or I came to the point, where I had to store stuff. And I didn't really know databases. I remember basically buying one of those O'Reilly books on MySQL, because I just felt that that's probably what I need. I had no idea.
CLAIRE: 00:11:18
Do you remember what the animal was on the cover of the book?
DANIEL: 00:11:20
I don't. I don't remember. But I do remember that I couldn't even install MySQL at the time, because this is in the era where the graphic arts industry was running a wide variety of systems. And mostly we worked on Silicon Graphics IRIX machines. That was the most popular one. A lot of Sun Solaris. But on top of that, there was everything else. There were Data General, DG/UX, NeXTSTEP, OpenVMS, all the way down to PDP-11s is what we came across. So the one database that I could get running basically ever was mSQL, which is available as an installer, mainly in IRIX, but also in Solaris. And mSQL is one of those weird databases that it started ironically, it has a Postgres connection, which I had no idea about at the time. It started life as a SQL library to Postgres when Postgres did not have SQL, when it was QUEL. But the ones developing it found that the Postgres engine was too slow. So once they had written this SQL layer, it was still too slow. So they had to write the database as well. And it became mSQL. And I think it's even still available today. But that was the first one that I used, mainly because it was there. And I didn't have huge needs for storing stuff. I just needed to store small amounts of data. And I didn't really know what I was doing in terms of databases. So this just sort of, it was there, it fit the bill. And that would be my first use of a sort of database in a commercial setting.
CLAIRE: 00:13:10
And then how did you transition from there to Postgres? Or I don't want to skip any really important steps. If there's anything formative or funny or interesting in between, let's go through that.
DANIEL: 00:13:23
Sure. I mean, I switched to Postgres on the 5th of March, 2005, at 3 p.m.
CLAIRE: 00:13:30
Wait, what? How do you know that?
DANIEL: 00:13:33
But I think I need to add some context to that before we move on from that point.
CLAIRE: 00:13:37
Okay.
DANIEL: 00:13:39
So what happened was that I was working in the graphics engine for a couple years. As so many others during the dot-com boom, you had a bed in the office and you were basically burning yourself out. Me too. So after a couple years, I figured it was time to sort of grow up and get a job. So I left that company and went back to university to actually get my degree. Because I come from a very academic family. So having a degree was very important to me. So I went back and studied computer science for my bachelor's degree. Which was very interesting having worked in the industry and then going to study it. Because I could value what I was learning in a completely different light than my classmates. Because I knew what I would need in the industry. But what happened was that this particular school that I was attending was very big on big projects and big sort of production-like projects. So all the projects we had in school had an actual company as a sort of buyer, if you will. So you didn't really make these sort of dummy apps just for the sake of writing some code. You actually got the requirements from a company somewhere. And you had to make a system that worked for them. When we were doing that, I was desperately trying to not have to write lots of .NET front-end code. Because that's really not what I like to do. And we were using Firebird as a database at the time. So I basically tried to implement everything I could in stored procedures. To save myself from having to write the stuff that I didn't want to do. And then another project, it turned into SQL Server. And again, I wrote everything as stored procedures. Just basically trying to skip away from the stuff that I didn't want to do. But it was all sort of lacking what I needed. Like I felt that it wasn't declarative enough. It wasn't powerful enough for what I wanted to do and what I needed at the time. And on that day in March 5, 2005, I was attending a conference in Copenhagen. Only because I was very interested in operating systems at the time. And that's sort of where my open source kind of avenue started. And I was there to listen to Robert Watson from the FreeBSD project. That was the reason I went to that conference. And then the ending session was also FreeBSD developers. I was really looking forward to that. And in between, I didn't really have much planned. Like it was, so I just, I don't really know why. But I went to, Bruce Momjian had a session at 3 p.m. I don't know why I went to that session over the other ones that were going at the same time. There was like three tracks or something. I can't explain why I went there. But I'm very glad I did. Because I sat down. And Bruce Momjian was going over, I think the subject was Mastering PostgreSQL Administration. And he was, but it was mostly like "this is Postgres". And he was just going over all the capabilities of Postgres. And I was sitting there, being completely blown away, realizing that this database has everything that I need and want. Because it has PL/Perl. I can write all the, I can write everything as a stored procedure. I can do, it was the programming environment that I was looking for. But I didn't know existed. And so from that day and time, I have not used any other database. Like that's when I completely just shifted over to using Postgres for everything.
CLAIRE: 00:17:52
I'm going to have to make sure Bruce Momjian hears that part of this podcast. Because that should make him feel good about all the time he invests in going to conferences and giving talks and helping not just experts but new people develop a perspective and knowledge about the database. That's really cool.
DANIEL: 00:18:13
I was completely blown away. It was just as if someone had heard what I was looking for and just laying it out in front of me. [So is that.] I do remember going back, so this was in Copenhagen, which is a train ride home to Malmö where I was living at the time. And I do remember compiling Postgres on my laptop on the train on the way back. Like I need to get started immediately. Like I just immediately got to work. And, yeah. That was definitely one of those moments in time that changed my career and life.
CLAIRE: 00:18:50
Did you walk up and introduce yourself to Bruce at the end? Is that the day you first met him? Or did you guys not become friends and colleagues until many years later?
DANIEL: 00:19:00
That was many years later. I did walk up to him because I had some questions. And he just confirmed, yeah, you can do that. Yeah, you can do that. But it was just, I was just one in the audience. It turns out Magnus Hagander, who is now a close friend of mine, was also in the audience that very day. But it took many years until I actually met him in person.
CLAIRE: 00:19:21
Wow. Because, yeah, I just assumed you guys had been good friends forever. You and Magnus, I mean.
DANIEL: 00:19:28
Yep. But not until many years after that.
CLAIRE: 00:19:32
Okay. So this explains when you first became a user of Postgres. [Correct.] I know when I talked to David Rowley, I think one of his perspectives is that his time spent as a user and also working with users, supporting other users, has helped him become, I don't know if it's a more empathetic, but a more effective developer and contributor to Postgres, right? Because you can stand in someone else's shoes, if you will. [Right.] So how did you make the transition from being a user to becoming ultimately a contributor? And what was your story? Do you remember another exact date?
DANIEL: 00:20:20
Kind of, sort of. [Uh-oh.] So I'm trying to remember all the details here. Leaving university, like after having done my bachelor's degree. So I was still not really, I'm not going to say that I was interested in databases at the time. They were a tool that I needed to do a job, essentially. They were just one of the tools that I needed to write the software that I was required to write. I was still mostly interested in operating systems at the time. The technical challenges for me was getting involved in operating systems.
CLAIRE: 00:20:56
And your favorite was Solaris, right? [Laughs.]
DANIEL: 00:21:03
I have a funny Solaris story for you later. No, I was a FreeBSD user. Obviously my favorite operating system at the time was IRIX. I had a Silicon Graphics machine at home on my desk. I was an avid IRIX user. But when it came to sort of the more practical side, I was using FreeBSD because that's what I could have on my laptop and things. [Okay.] But leaving bachelor's degree, I moved to Australia to do my master's degree. And I was still trying to pursue, like for my thesis, I was still looking for an operating system topic But it turned out, like, the professor that I really wanted to work with, he was a database guy and still is. So I chose one of his topic ideas mainly because I wanted to work with him. And I figured I know this Postgres thing and I know I can use that to do this thing that we're supposed to do. And that's when I really got excited about and interested in not just using a database but actually writing one and implementing things inside the database, database internals, spending that year for my thesis. So that's basically when the kernel came of, like, maybe this is what I'm interested in. I thought operating systems was my thing, but clearly this is more exciting. And then coming back after my master's, I started working for a company that does or did classified ad websites, essentially like a Craigslist type thing where there's clearly a lot of data. And it was using Postgres and it was using some rather clever tricks. So I was transitioning there to being, again, sort of a user of Postgres. But it was a very open source heavy job. And there was a lot of open source contributors working there. So it became pretty natural that you start poking at the code of everything and Postgres included. And at that job, I went to the CHAR(10) conference in Oxford, which was a Postgres conference that I don't exactly remember who organized it, if it was 2ndQuadrant or if it was just Simon Riggs personally.
CLAIRE: 00:23:43
Can you say the name of it?
DANIEL: 00:23:45
CHAR(10) It was a backronym of clustering, high availability, and replication. [Okay.] But they called it CHAR(10) because it sounds like the data type in Postgres of 10 character char. So it was a funny, kind of a dad joke among database folks. But I remember coming to that conference and realizing that there's a community. Like I came knowing absolutely no one and was immediately welcomed by everyone. And spent hours talking with Simon Riggs and others. So I think that's when I realized that this is what I want to do. Like this is where I want to get involved. Because these are some fantastic folks and it's a technology that I'm interested in. So definitely that conference is where I just sort of transitioned in my head from being a user to being sort of aiming towards being a contributor. And then it took a couple more years because I moved to Australia again. And coming back from that was when I, more and more started, you know, poking at the code and eventually led to submitting some patches and getting involved in organizing conferences and things around 2014. But CHAR(10) in 2010 in Oxford was definitely the point where I made the mental switch of this is what I want to do.
CLAIRE: 00:25:26
On the chat, Melanie Plageman commented that it's funny how you often hear people mention conferences as how they got more involved in open source development.
DANIEL: 00:25:37
And it's all about the people. I mean, I'd been looking at the code. I'd been submitting patches to open source projects and I'd been involved in, I'd been a committer on other open source projects for many years up until this point. But meeting all these people in the Postgres community and immediately feeling welcome, was that sort of like, yes, this is what I want to do.
CLAIRE: 00:26:03
Do you think those experiences, because they were formative in how you got involved with the Postgres project as a developer, contributor, do you think that is part of why you then also got involved in organizing conferences and serving on talk selection teams? Because I know that's something, well, not only with Nordic PGDay, but with some of the other big Postgres events, that you've given a lot of time to.
DANIEL: 00:26:32
Yeah, for sure. I at that point realized just like the value of these events and just how important they are, and how much fun they are. And so when Magnus and Claes, which was the three of us who started Nordic, the two of them had been thinking about getting a conference going in the Nordics or in Stockholm. They approached me at a Stockholm Postgres user group meeting back in 2013. Like, hey, do you want to be a part of this? Because I mean, I knew of both of them because we're in Stockholm, we're in open source, we're in the same PUG, we met in Oxford. And like, yeah, sure, I want to be involved in that. And then once we'd done Nordic PGDay, the first one was in 2014, I was invited to help out with PGConf EU, which I'd been attending for a couple years up until that point. And knowing just how important they are and how much fun they are and how sort of like the value of them, I immediately felt like, yeah, this is something I want to be involved in, for sure.
CLAIRE: 00:27:47
I actually feel really lucky. I first met you at Nordic PGDay back when it was in Copenhagen, but this is like six years ago, 2019 or something like that, right after Microsoft had acquired Citus. And I don't think we'd met before that. Am I right?
DANIEL: 00:28:08
That was the first time, yeah. It was sunny Copenhagen. It was one of those weird days when March was really warm and sunny in the Nordic region.
CLAIRE: 00:28:18
And this changes countries and cities each year, right? [Yes.] So last year it was in Oslo and this year it's going to be in Copenhagen again, at a magical location. It's right on, is that a river? Some kind of waterway.
DANIEL: 00:28:34
Yes, the canal going in from the ocean, yeah.
CLAIRE: 00:28:37
So anyway, I'll drop the link into the show notes for anybody who wants to go to Copenhagen in March this year. I think the CFP is already closed and I don't know if the schedule is out yet, but it's really a lot of fun.
DANIEL: 00:28:53
Yeah, we do move it every year in order to make it affordable for everyone to come, because not everyone can get their company to send them across the world or even just across the Nordic region. I mean, hotels do cost money and being away from the family is not easy for everyone. So if we constantly move it around, at least someone can, at least those who can't really travel can at least attend the event every couple of years at a very affordable price, because we keep the tickets as cheap as we can. So the idea with the moving is to make it accessible even to those who sort of don't have the luxury of business travel.
CLAIRE: 00:29:34
Well, that's part of the thinking behind POSETTE as well. So it's virtual. The idea being a lot of people, maybe they're between jobs or they can't get business travel budget or they're just, they've got too much going on in their personal lives or too much going on in their work lives. And so the idea of having these high quality talks that are available to anybody who can get to YouTube, who has an internet connection, is part of the motivation for being virtual. And of course
DANIEL: 00:30:11
I think it's good to be that inclusive. We need to include those who can't afford to fly across the world. So I think that's really important.
CLAIRE: 00:30:19
Okay. So let's go back to your developer story for a second. Please remind me to come back to POSETTE at some point later because I know the CFP is open right now. But do you remember your very first patch submission? And what was it about? You don't.
DANIEL: 00:30:35
I have no idea. I don't remember. I remember my actual first patch submission to anything. That was a game that I wanted to play on IRIX, but it didn't work because it was written for Linux. So I had to patch it in order to compile it on IRIX. And I submitted it to the author who then included, that was my actual first patch for anything. When it actually comes to submitting a, what we today know as submitting a patch.
CLAIRE: 00:31:12
And they accepted it, I take it.
DANIEL: 00:31:14
They did accept it.
CLAIRE: 00:31:15
And you got to play your game.
DANIEL: 00:31:17
Exactly.
CLAIRE: 00:31:18
All right. Very cool. If you don't remember your first patch submission to Postgres, what parts of the system did you work on at the beginning? Did you pick something that was super crazy challenging? Or was there a part of Postgres that you just have naturally gravitated to working on?
DANIEL: 00:31:40
So I've been spending a fair amount of time working on the networking side, mainly around the TLS support. Not really sure why that happened. Probably because, so one of my other open source hats is that I work on curl and libcurl. So where I'm obviously exposed to a lot of TLS libraries and TLS weirdness. So it became natural, like, once I'm doing something in curl, I can, maybe that same problem exists in Postgres, and that sort of crossbred into me looking a lot at the TLS layer in Postgres. But it wasn't sort of like this specific, I'm going to be the TLS person. Like, that just, it just sort of happened. And these days I'm getting a tremendous amount of help from Jacob Champion, who is going to hopefully take over a lot of that responsibility from me, because he's doing amazing work there. But I haven't really focused on any specific area. I've been poking at basically everything. The one thing that got me started in looking at Postgres code is the one patch that I still haven't written. But the very first feature that I wanted to do is one that I still have on my to-do, which has been there since 2010. But someday I might get to it.
CLAIRE: 00:33:13
Are you going to tell us about it? Or is it something that you don't want to tell anyone about? Because you don't want to increase demand for it.
DANIEL: 00:33:23
It's the, when you write a stored procedure, I'm trying to remember all the details, because I haven't written stored procedures in so many years. Because at that job that I had for the classified ads websites, we did a lot of stored procedures. Like, we had implemented a lot of the logic in stored procedures. And when you write a stored procedure, you can say that I want variable foo to have the same data type as parameter bar. So whatever parameter bar is passed in as, I want to have this variable be the same data type. Because I'm going to assign it, and I'm going to do some calculations on it. So it's like a shorthand notation for, rather than having to specify, yes, I want this to be an integer as well, and then you need to remember to change it if you change the parameter type. And there's a shorthand syntax for that. But that doesn't work if you're declaring an array as a variable. You can only declare a variable, like one variable. You can't declare an array of that type. And that was bugging me, because we were doing that a lot. So I wanted to fix that. But I never got around to it. At the time, it was sort of over my head to write that code. And now it's just one of those things that still sits on the to-do list for a rainy day that hasn't come yet.
CLAIRE: 00:34:52
The day will come. You'll get there. Make sure you come back and tell me when it finally happens. So one of the questions I like to ask people, like, if you imagine somebody's listening to this show, who obviously a whole bunch of people who are here in the live text chat are already avid or active Postgres contributors and developers. But let's say someone's listening to this who isn't yet part of the Postgres community. They're not yet a Postgres contributor, but they're thinking about it. Or the same for users. Maybe they're just deciding what database they're going to go with. If you end up talking to someone like that and they ask you, "Well, why should I use Postgres?" What's your answer versus some other database?
DANIEL: 00:35:44
I mean, that's a good question because the answer depends so much on the use case. And to be fair, there's probably a lot of times when Postgres isn't even the right answer for them. And we shouldn't be, we should totally acknowledge that there's a plethora of other technologies out there. But in general, I would say that Postgres is where IBM used to be, you never got fired for buying IBM. And these days, you don't really get fired for implementing Postgres in your project because it's like this safe alternative, it will scale to your needs. It will handle your load. And it's not going to ruin you cost-wise because it only costs as much as you want to invest in support contract with a vendor somewhere. If you don't want to spend anything, it's your own time. And it's this technology that will just simply be around. And even if it's not around, it's still sort of using SQL, which is a standardized tool, so a standard language. So most of the skills are transferable to something else. So I would say it's like this, I'm not going to say it's the simple, boring, choice. It's the exciting choice that will fit almost every need you have. It might not fit every, the most specialized needs, but it's going to fit basically everything. It's going to do an okay job to a great job everywhere. So it's like the stable choice of buying IBM.
CLAIRE: 00:37:18
Got it. You mentioned SQL as the standard language. Is that something you ever got really good at, writing SQL queries?
DANIEL: 00:37:36
I would say I was definitely above average when I was doing it every day. But that's not true anymore. It's like this, you learn French in school, and unless you speak French, it's simply sort of, it doesn't really go away, but you definitely get worse and worse at it. I don't write enough SQL these days to feel that I'm good at it, and that's one of the things that I would like to change, because I want to, sort of, relearn all the skills. I definitely had a period in time when I spent all my day writing SQL, essentially, or SQL as stored procedures.
CLAIRE: 00:38:22
So how did you get good at using Postgres, writing SQL, writing stored procedures? Obviously what you're saying is by doing it every day, you learn through experience, you learn through that familiarity, and building those muscles, if you will. It's like going to the gym. You have to go to the gym if you want to get in shape. But are there other things you did, things you would recommend? If you had a nephew or a niece who was just getting started, had a new job, had to learn Postgres, what suggestions would you give them?
DANIEL: 00:39:02
That's a hard one, because it's been so long since I was in that position. I think for me, SQL felt very natural, because I grew up on weird programming environments and programming languages. The stuff that I started out learning was not just your normal, the Java, Pascal. There were so many weird languages that I learned over the years. [Like?] A lot of them. For example, in the early '90s, I was given a modem, and I started calling BBS systems. That's basically when I shifted over to, "I want to write software," because I found this world of people sharing their software as shareware, and I wanted to be a part of that. One of the things that I did a lot back then was writing add-ons to BBS systems, because basically all of them had some way of writing software, like plugins essentially for them. A lot of them had their own programming languages. PCBoard was a very popular one. I think it was called PPL, PCBoard Programming Language. There was a lot of others. Some of those were declarative, kind of like SQL. Coming to SQL felt sort of natural, because I had seen so many different weird things and declarative things that, I don't know, it just sort of felt fairly natural, and I could apply the learnings that I had from all this previous exposure. My way into SQL is definitely not transferable to anyone else. That's probably a good thing, because I'm pretty sure there's a lot of better ways out there.
CLAIRE: 00:41:05
Okay. If you were to give advice to your niece or nephew, you'd probably have to go do some research, because you wouldn't recommend they follow the path that you took.
DANIEL: 00:41:17
No, I would have to ask Bruce, or someone.
CLAIRE: 00:41:21
Okay. What about failures versus successes? As you got started in Postgres, did any stories come to mind about, I don't know, big mistakes that you made that you're never going to make again, or easy wins in those early days as a contributor?
DANIEL: 00:41:47
That's a good question. I think my biggest failure is not asking for help. Maybe it comes from being an introvert Scandinavian, I don't know. But I've never really reached out to anyone to, maybe not as much as mentoring, but just asking for help on things. I've just stubbornly been sitting on my own, trying to get this thing to work, whatever. Obviously, when you do get it to work, that's a great sense of achievement. But I'm pretty sure that I would have come further in my journey had I reached out to folks and sought more assistance and help, especially in the early days. So I would say that's probably my biggest weakness. And that's why I'm so, so, so glad that Robert Haas and others are sort of picking up this mentoring that we're starting to do now a lot more. Because I think it's super important, and it's something that I would have wanted to have starting out. So, yeah, that's probably my biggest failure, if you will.
CLAIRE: 00:43:04
So just as context for someone that's listening, Robert Haas is another Postgres committer and major contributor. He works at EDB, has been involved in Postgres for a long time, like Daniel. And he just has kicked off, I guess it was last summer of 2024, a new mentoring program for current Postgres contributors or aspiring Postgres contributors, where they each have gotten, the first cohort is happening now. And, in fact, Robert is going to be the guest on the next episode of Talking Postgres in February, which maybe you knew, maybe you didn't. But it's a perfect opportunity to mention that. On February 5th, we'll do the live recording, and the episode will come out a couple days after. And we're going to talk about mentoring in Postgres and why it matters and why he started this program and how Melanie Plageman influenced that and all sorts of things. Did I miss anything on that context?
DANIEL: 00:44:12
No, I think that's about it. I think it's a super important and valuable program that I wish we had earlier. But, yeah, it's fantastic that we have it now.
CLAIRE: 00:44:25
Yeah, and to be fair, I'm sure that mentoring has happened among Postgres contributors for many, many years now, but it's all been kind of informal. And sometimes the person who wants to be mentored has had to go ask for it themselves, like figure out amongst all the people, well, who's the right person to ask and go and ask them and somehow. So it's nice to have the structure, I think, in place.
DANIEL: 00:44:54
Yeah, for sure. And as you say, it has been happening and it's been probably happening a lot because folks in this community are very approachable. So it's not that mentoring hasn't happened, but it hasn't been sort of like an official visible thing because a lot of people would not dare to send an email to Robert Haas or Peter Eisentraut or someone and ask for help. Like, it just seems like you can't really do that. Like, surely these people have so much more important things to do. Now, a lot of these folks will immediately answer your question. Like, there's, and that's been going on for a long time. But to have it as an official public thing, I think that's very valuable also for those who didn't realize that that's a thing you could even do. So, yeah, I'm very excited about that.
CLAIRE: 00:45:50
Okay, so let's talk for a second about, okay, you work at Microsoft. But my understanding is the vast majority of your time, your work day if you will, is spent focused on the Postgres open source project, the upstream project, is that correct?
DANIEL: 00:46:11
Correct, yes.
CLAIRE: 00:46:12
Okay. And you are both an individual contributor in some of the work you do, but you've also just taken on a management role as well. So there are other Postgres contributors at Microsoft who work on the upstream open source projects who now report to you, correct?
DANIEL: 00:46:29
That's correct, yes. [Okay.]
CLAIRE: 00:46:32
So what I'm curious about, just now that we have that context, is when you think about contributing to the community, obviously if I go back and look at, like, the number of patches you reviewed in the last release or the commits that you've done, the contributions you've made, you're obviously contributing to the code. But you've also spent time doing other community things. Like, obviously you're a guest on this podcast now, but you've helped to organize conferences. And what I'm curious about is why. Why did you spend that time?
DANIEL: 00:47:04
Organizing conferences? [Yeah.] I mean, mainly because I think it's an important thing to do. And it was, I'm not going to say it was an easy thing to do, because it wasn't. It's been a lot of hard work. But it's sort of like this starting out, it was something that was very approachable to me, because I knew I could do it. It wasn't, you know, writing something very complicated piece of code. It was the more human side of organizing events. Like, it was something that I knew I could do. And it was something that I enjoy doing. And I value just how important they are. And I got to, you know, do it along with friends, like Magnus and Dave Page and everyone else. So it was sort of like an easy, like, once I got approached to ask if I wanted to be a part of the PGConf EU organizing team, immediately it was obviously an honor to be asked. So definitely don't want to turn that down, and obviously these are people that I like, people that I hang out with. So, sure, I want to be a part of that. And then it just sort of snowballed from there. And I spent a good part of ten years doing that. Up until basically last year, when I felt that it was time to, it was time for a change. Like, I needed to do less of that to regain sort of the excitement about doing it. And also to have more time for other things, essentially. Because it does take a lot of time, that's for sure.
CLAIRE: 00:48:36
Yeah. A lot of blood, sweat, and tears. But you are on the talk selection team for POSETTE this year.
DANIEL: 00:48:43
Yes, I am.
CLAIRE: 00:48:45
Okay. And the CFP is still open. And we'll close on, for anybody who's listening to this right away and is just hearing about POSETTE for the first time, it's that virtual event for Postgres that is organized by Microsoft that has a lot of speakers from outside of Microsoft in the open source world, as well as some, like, Azure Database for PostgreSQL customers. And anyway, the CFP will close on February 9th. So I guess you'll be doing talk selection later in February then.
DANIEL: 00:49:14
Yeah, it's going to be exciting. Looking forward to that.
CLAIRE: 00:49:18
I think that, I guess, you know, other technologies, when there's a company behind them, a company is the primary supporter of that project, a lot of times that company is the organizer of all the events. But the thing that's special, I think, about Postgres is that there is no one company, right? People contribute from all sorts of different consulting companies, big cloud companies, all over the place. And so, as a result, that means that the big events, the PGConf EUs of the world, the Nordic PGDays, as a smaller one, they do need support from volunteers. And that's what you've been doing for a long, long, time, which is awesome.
DANIEL: 00:50:01
It's all volunteer driven, which is pretty impressive considering how large and complex these events are. And obviously, they started out small and have grown. And as they grow, the experience of those organizing them grows with that. But still, every time I'm involved, I'm always almost surprised at how, what the scale of operations that we can support with relatively few volunteers. And obviously, we are supported by companies because the sponsorship money is super important for these events and the sponsorship support in the sense that basically, every conference that I think I've been involved with, the ticket prices are mostly at cost for the organizers and sometimes even below cost to keep it affordable. And then the sponsorship money is what's bridging it up to pay for everything. So, at Nordic PGDay, we've many times had actually the tickets, the general attendance ticket, being below cost for us and relying completely on sponsors to make up for being actually being able to pay for it. And that's always been working out.
CLAIRE: 00:51:26
So, you're bringing to mind a picture of one of those slides from that talk that you and I worked on together. For Postgres, so, for anyone who's not familiar with the Postgres release cadence, there's typically one major release a year. It comes out around September-October. And the actual code freeze, or development freeze, what's the proper term? What do you say? [Code freeze.] Okay. Well, there you go. It generally happens, is it beginning of April?
DANIEL: 00:52:01
I think so. Roughly around the end of March, early April.
CLAIRE: 00:52:04
Yeah, there's a big commit fest in March. And a lot of stuff happens. Happens or doesn't happen in that month. But there's, so, we have this cycle. And for last year's PGConf EU, you and I collaborated on research of a talk looking at all of the different contributions to Postgres version 17, which turns out, like when we mapped it out in the calendar, it was like a 16 month time frame, start to finish, from when the branch was forked in the code to when GA happened. And so, anyway, we tried to look at as many different types of contributions as we could. Obviously, you did a whole bunch of research on the code contributions, looking for, well, what's the oldest piece of Tom Lane code that was modified? And there were a whole bunch of interesting little juicy tidbits that came up in that work. But we also looked at sponsorships, like you're talking about, and, which companies gave most frequently, which companies gave the most in terms of dollars. And there's this chart that has all the logos from all the companies that sponsored all of the Postgres community events that we looked at. And it's just phenomenal. Like, the financial support is important, I guess. That's a long way of saying that.
DANIEL: 00:53:20
Yeah, it's very important. And it's nice to see that all these companies pulled together to really support the community. So, yeah, that's very important and sort of heartwarming for those of us to spend a lot of time and effort in making these events, that the companies come around and help us out financially.
CLAIRE: 00:53:43
I'm going to drop the slides from that talk into the show notes for this show, too, for anyone who's curious. Because it's, I don't know. We were surprised. Well, first, we were surprised by how much work it was to do that research. And then we were also, I think, just surprised by some of the patterns we saw and people who were frequent conference speakers, for example. And so, all right, I want to pivot back to some of your development work as well on Postgres. And I'm just curious, can you, would it be interesting to walk through your toolset? Are there favorite tools that you use as a Postgres contributor that maybe people should be using but aren't?
DANIEL: 00:54:33
Actually, not. My tool set is very boring. So, like I said earlier, working in the graphics arts industry, I came in at a point in time where there was still a very wide variety of systems out there that we would be working on basically daily. So, and quite often, in order to reach the system I had to go to, I had to, you know, telnet. Generally, SSH wasn't even available on most of these systems. You had to telnet through an IRIX machine onto a Solaris machine via DG/UX and then the next step. Many of the environments had been set up by, you know, network engineers who weren't that by trade. So, there was very interesting networks setups. So, I had to jump through all these hops and reaching the final system, nothing ever worked except just your A to Z on the keyboard and vi was the only thing available universally. So, from that time, like, I only use vi. I don't have any plugins, I have nothing else. I only use vi and a terminal because that's what I sort of, not because I grew up with it, but that's what I, where I cut my teeth in UNIX development. So, I'm still just using vi and a terminal and nothing else. I do have syntax highlighting mostly because it makes at least, makes the screen a bit brighter, but I honestly don't even know what the colors mean, it just looks nice, but I have nothing else. So, my tool set is very, very minimal.
CLAIRE: 00:56:22
So, you use syntax highlighting for the aesthetic pleasure you get from it.
DANIEL: 00:56:27
Yeah, pretty much. I'm very bad at learning new tools and also I'm getting older, I'm just not terribly excited about configuring a new tool and learning one. It's like, I just want to get to work, so I stick to what I know, essentially.
CLAIRE: 00:56:46
There's a really famous phrase that says that the best tool is the familiar tool. And I feel like that's part of human nature. Like when someone has been trained on using a particular system and it still works. Obviously if it isn't working, I know you, I know that you're going to go find a better way. But as long as it's still working, why not use the familiar tool?
DANIEL: 00:57:10
Yeah, and even going all the way back to my early, early days of early, like pre-DOS, like when I was working, I don't even remember which computer that was, but we had a CP/M machine at home and it was shipping with WordStar, which I believe was the sort of like origin of vi, because it has the same key bindings. So it had that familiarity even from when I was like eight years old. So that's probably another reason why it's part of my muscle memory.
CLAIRE: 00:57:49
I had no idea there was a relationship between WordStar and vi. I'm really curious about that. OK, I'll go research that after the fact. Because I too used vi when I was first starting out as a developer. So I was never an Emacs person. All right, so have you heard me talk about this phrase called the toothbrush test?
DANIEL: 00:58:13
I've heard you mention it, yeah.
CLAIRE: 00:58:15
OK, so the idea is when you're brushing your teeth in the morning, are you looking forward to the work that you're going to be doing that day? Or are you dreading it? Obviously, if you were dreading it, you probably wouldn't be on the show, because you probably wouldn't want to be talking to the world about your work. So I'm guessing your work on Postgres does pass the toothbrush test. But I don't know. Tell me more. What's going through your head as you're starting your day?
DANIEL: 00:58:42
I do enjoy it. I do still enjoy it. I couldn't really, I mean, it's been a career for so many years that I can't really imagine doing anything else at this point because of all the people that I interact with, and I'm still excited about working on the Postgres code and making Postgres better, because I've seen so many of the shifts since I started using it back in 7.0.3 or something, 7.0.2 perhaps. So it still excites me. But these days, I guess I'm more shifting towards being sort of excited or interested in trying to review and help others make things rather than making everything myself, essentially. So that's where my interest is leading me towards nowadays. But I'm still excited about it. It's still sort of top of mind in the morning, after getting the kids to school, obviously, because that comes first.
CLAIRE: 00:59:58
Well, and I know from my perspective and the kind of contributions I make to Postgres are not in the code base, right? They are other contributions to the community. But being able to reach out to you to get your advice, to get your counsel, to get your feedback, is huge. And I'm sure that the developers on the team on the project feel the same way. It is pretty awesome when people are willing to spend part of their time reviewing other people's work and helping make other people get better. So I will pass on gratitude. Let's look backwards for a second. What advice would you give to your younger self about getting started as a developer?
DANIEL: 01:00:46
I think I'd circle back to what I said earlier. Like, don't be afraid to ask for help. Because I think that's one of the things that I could have done more, for sure. And, yeah, that's definitely the one, that the advice I would give to my younger self. I probably, my younger self wouldn't have listened. I would still say it.
CLAIRE: 01:01:13
Or wouldn't have listened right away, maybe. Like, sometimes I had this engineer who worked for me once, and I used to tell him that he wasn't the model for the world. Because he would often judge other people's behavior based on, like, what he would do, right? And he had these super high standards. And when other people didn't meet it, it got him immensely frustrated. And so I would just be like, look, you can't use yourself. Not everybody's like you. You know, you have to have some empathy. Anyway, didn't listen, didn't listen, didn't listen. I got a phone call like three years later saying, I finally understand what you mean. Or finally understood what you mean. So sometimes it just takes a while to sink in.
DANIEL: 01:01:53
Yeah, for sure.
CLAIRE: 01:01:55
Let's look forward. And I didn't tell you I was going to ask you this, so I'm kind of putting you on the spot. If you had to imagine what Postgres is going to be like in five years, six years, seven years, any thoughts or predictions for the future? Or rather, maybe it won't be like that, but you hope it's like that?
DANIEL: 01:02:21
I think I have a pretty boring answer there. I hope that Postgres in the medium to short term, so say five, six, seven years ahead, is a better version of what we have today. Like I don't want a revolution. I want an evolution. I want Postgres to be, the people who today are investing in putting Postgres in their tech stacks, I want them to feel comfortable that what we ship in five, six, seven years time will still work for them. Because I've been on so, so many systems that are ancient. Like I said, I've been working on a PDP-11, and they were definitely not the computer of the day when I was working on them. Like systems live for a long time. And having that stability of your database just being there, and you don't have to stay on an end-of-life version. You can keep following along. That's what I want Postgres to be. I want Postgres to be that choice that just always works for you. It might not be the shiniest tool always. It might not be the most fancy tool, but it's just always going to be there for you, and it's just always going to grow with you. That's what I want Postgres to be.
CLAIRE: 01:03:50
I don't think that's a boring answer at all. [That's good.] I like it. Okay. I'll figure out how to weave that one into the show notes. Did you want to give a shout out to PGConf.dev?
DANIEL: 01:04:06
Oh, for sure. It's one of those, so, last year we picked up where PGCon left off essentially. So last year we formed a new corporate entity in Canada to pick up a new developer conference. Because PGCon had been running for many years, and it was clear that Dan, who was running the conference, needed help and needed to be sort of, like, he'd been doing it on his own for so many years, and we just needed to step in and help him out. So we formed this and made PGConf.dev, which was intended as sort of like the successor to PGCon, to bring the spirit of PGCon, but revitalize it. And I hope it did. I wasn't actually there because I couldn't travel for personal reasons, but I've heard from so many people that they immensely enjoyed the event. And this year is going to be even better, probably because I'm not there, because I left off organizing it to a new group of people who are very good at that. So I'm really looking forward to it, and it's going to be an amazing event. And anyone who's interested in Postgres development should definitely try to make their way to Montreal to attend, because it will be a phenomenal event. And it's going to be that one event of the year that most of all the developers will attend, which is super valuable to have the access to all these brilliant minds who work on Postgres every day and sort of be able to pick their brains in the hallway track.
CLAIRE: 01:05:51
Okay, but I have to disagree with what you just said. It's not going to be better because you're not involved. You're just fishing for compliments.
DANIEL: 01:05:59
No, no, no. We have a new team, which is really good. I'm very, very confident in their making a fantastic event.
CLAIRE: 01:06:07
I am too, but it's not because you stepped back, okay? Yeah, I remember I went last year, and it was the first year in this kind of rebrand version 2.0 of the Postgres developer conference, and it was in Vancouver, so yeah, last year is correct, 2024. And I remember being in the airport at the same time as KK and Jeff Davis as well, and they were both just like, and Jeff is kind of introverted, but they were both bubbling over with joy and stories and just how invigorating and exciting and how much value they got out of talking with others in the developer community. So yeah. All right. Thank you for the shout-out.
DANIEL: 01:07:01
I'm very much looking forward to attending this year.
CLAIRE: 01:07:04
Okay, so let's see. I have a question about whether there are any books or blogs or tutorials that you want to recommend to other Postgres developers and contributors who are just maybe getting started or just thinking about contributing to Postgres. Do you have any go-to's that you want to share? Even if they weren't things that you used because the way you got started with Postgres is not necessarily one that people should follow.
DANIEL: 01:07:35
Right, right, right. I don't, actually. I wish I did, but I don't really have any good suggestions there.
CLAIRE: 01:07:44
Okay.
DANIEL: 01:07:45
My go-to for programming is still to read the classics. Now, by classics I mean the Dragon book, the Purple book, and the Practice of Programming, which are all books that came out probably 20, 30 years ago. But they are such seminal pieces that they still hold up today. Now, they are definitely not for everyone. But I think for me, that's my go-to answer.
CLAIRE: 01:08:24
Okay. Got it. I'll make sure we include those links in the show notes as well then. There was a question on the chat from KK, I think. We kind of glossed over your involvement in the curl community earlier. We only touched on it briefly. But I think he was curious to know more about how you got involved in that project.
DANIEL: 01:08:48
That actually has a Postgres angle as well. So I don't remember the exact date. So I can't give you an origin story I like for Postgres. But many years ago, like I said, I've been very bad at asking for help. And I came to a point where I was hitting a wall. I couldn't, like code-wise, I couldn't really, I didn't progress anywhere in Postgres. And I was getting a bit frustrated. So I was kind of looking around for other C-based projects to sort of, as a mental break, as doing something else for a change. And curl is famously run by Daniel Stenberg, who is another Stockholm guy. And I knew of him and kind of knew him from meeting him at open source conferences here in Stockholm and events like that. So I kind of just figured maybe I should just look at curl for a change. Because, I mean, it's C. It's a C code base. It's very approachable. It's kind of like what I was looking for to still do programming, but not in Postgres for a while. And I just started poking around a bit and immediately realized that this is also a community that I like and people that I like working with and hanging out with. And it's an interesting piece of code. And it's obviously a very different project from Postgres where, like the scope of changes you do in curl has such a big impact on everything. Like, I mean, it runs in like billions of devices. So, but at the same time, it's like, it's a tiny community. When I got involved it was like 10 people who was regularly contributing to curl, and one of them doing the lion's share, the share of all the work. So that's where I get started. I was just interested in doing something else for a change, and then that snowballed into getting a commit bit and becoming a maintainer. And now I don't do as much as I wish I had time for because I was having small children and working full-time on Postgres. I don't have all the time in the world to spend on it. But I'm still on the curl core team and security team. So I try to keep on top of those things, and I wish I can, I hope to get back into doing some more stuff on curl in the future, but we'll see when I have some more time. But that's really the reason. I needed a break from Postgres. And in doing something else for a change got me excited about Postgres again because I kind of realized, you know, I miss working with this code base over here. So I think curl in some way kept me in Postgres.
CLAIRE: 01:11:54
It's interesting because I think a lot of people need, you're going to burn out if you do the same thing all the time, all the time, all the time, right? So you need a break. You need an outlet. And for some people it's exercise, or for other people it's, I don't know, reading or Netflix series or whatever their hobbies are. You know, some people like to do pottery in their spare time. But it sounds like for you it was curl, or it is curl.
DANIEL: 01:12:25
Yeah, curl was the stuff that I needed at the time for sure. And then it grew into being a fairly big member of that community, or for a while it was. Now I'm more of a fringe member. But, yeah, that was what I needed at the time for sure. And it's still an exciting project. I mean, as I said, it's still exciting to work on something that is so widely deployed as curl.
CLAIRE: 01:12:55
Okay, so the topic of this episode was how I got started as a developer and in Postgres. And I feel like we covered a lot of ground. Like I feel like somebody who listens to this is going to have a better understanding of your story. Is there anything, though, that's part of that journey, getting started as a developer or in Postgres that I didn't ask about? Or you have scribbled on a piece of paper next to your desk that you wanted to be sure to mention that we haven't touched on yet? I think we've touched on most of the things. Definitely when it comes to Postgres.
DANIEL: 01:13:33
The one thing that I did scribble on a piece of paper here was, because I was thinking earlier today, like when did I not just got interested in writing programs, or doing some form of program, but actually interested in making sort of like a coherent program that someone else could use? Like making software essentially. And that's definitely, that brings back to when I got my first modem and started calling BBS systems in the early '90s and finding out about this shareware world where people were sort of freely sharing their, it wasn't code, they were sharing like programs. And I just remember like all of a sudden realized I have access to this giant library of basically anything that I need or want. And that was just coming from sitting on your own, like you have your computer on your desk and the software you have is, the stack of floppies next to it, to I can have anything I want. That was really sort of mind-boggling at the time. I was like 11, 12 years old. And I just want to be a part of that. So that's when I wrote my first actual piece of software that was then distributed. And it was a guitar tuning software because I was playing the guitar at the time or trying to. So it was a software for helping you tune your guitar. It would play the tunes in the PC speaker so you could sort of tune your guitar at the same time. [That's really cool.] And I really sort of realized that I want to make a piece of software, you know, with documentation and everything around it, and then ship it out to the world. And hopefully someone uses it. And that was just really exciting. And that's definitely when that spark was lit.
CLAIRE: 01:15:42
Do you still play the guitar?
DANIEL: 01:15:43
I don't. I never really learned, to be fair. I was never any good at it. And I gave up at some point after that.
CLAIRE: 01:15:54
Do you still own a guitar?
DANIEL: 01:15:56
No, no, I don't. I still own my trombone. I was a trombone player when I was young. I still own that, but I haven't played in many, many years. I guess my son will inherit it or my daughter will inherit that. And maybe they will pick it up. I don't know. We'll see.
CLAIRE: 01:16:14
I like that goal, though. I want to make a piece of software. And what's interesting is I would want you to strengthen the goal. Instead of I want to, your goal from when you were a young kid. Instead of I want to make a piece of software that I hope people use, it's like I want to make a piece of software that makes people's lives better. But I guess we can't go back and change your young child goal.
DANIEL: 01:16:38
No, that wasn't really on my map when I was 11. I was mostly interested in making something. But I do think the whole open source movement and what we have today is making lives better because we are empowering people to, I mean, you could start a company with everything you need for free, essentially, and anything can be tailored too. I think that's such a powerful gift in computing that open source has brought along, that we're empowering so many people on this planet to do the things they want to do without being sort of locked into anything or being forced to, like I can't start this company because I can't afford this product over here. There's alternatives for you for everything. I think that's really powerful.
CLAIRE: 01:17:36
You talked earlier about how you're trying to focus some of your time on helping other Postgres contributors, right, with patch review or with mentoring or all the ways you help people. And one of the things that people don't realize, like behind the scenes on this podcast, right, there's a lot of work involved in figuring out who are our future guests and recruiting them and, you know. Luckily, almost everybody says yes when we invite them, which is pretty cool. But you have been in the background helping me make this podcast and make it better. And you were actually a maybe for quite a long time before becoming a yes. So I think I have two questions for you about the podcast. Why has it been worth spending any amount of your time advising me on having a podcast geared toward people in the Postgres community and the Postgres developer world? And then, of course, I'm going to ask you about music next. But let's start with the first question.
DANIEL: 01:18:41
Well, I find it sort of important for almost a selfish reason. I love listening to podcasts and I've been listening to podcasts since, I don't even remember, the early 2000s, late '90s or something. It's been my source of listening pleasure for so many years. But for many, many years, I lacked, I felt there was a lack of Postgres content. There was never a Postgres podcast. For many years, there was nothing. Now there's a couple, this included. So for me, it's a selfish reason. I want to hear a podcast about Postgres and the people behind Postgres. And I also find it super valuable for the community to have this resource. So it ticks all the boxes for me. It's important for me as a person, but it's also, in my mind, important for the community and for those starting out to have this resource and to hear the stories of the people who is making this thing. So yeah, for sure, it was a no-brainer to help you with that. It was a much easier decision than to come on the podcast.
CLAIRE: 01:19:58
Yeah, you were a maybe for quite a number of months before you turned it into a yes. And I didn't actually probe you on why the switch from a maybe to a yes. I just took the yes and ran with it. I'm like, okay, how about January 15th? So I'm really, really glad that you were able to say yes and make time to be with us here. Before we wrap, I do want to ask, though, what was your final recommendation on whether we should add music? Not for your episode, unfortunately, because I can't turn that around in 48 hours. But should we have music in the intro and the conclusion moving forward?
DANIEL: 01:20:33
I think you should, yeah. As I said to you earlier, I'm old. I come from a talk radio background, like listening to radio. There was always the music when the program started. So for me, that just makes it a grand whole. Yeah, I definitely think you should have some form of music to start.
CLAIRE: 01:20:54
Okay. We'll work on it. We'll see what Aaron and I can come up with.
DANIEL: 01:20:59
I'm excited to hear.
CLAIRE: 01:21:01
All right. Well, thank you very much, Daniel, for joining us today. I've really enjoyed learning more about your story. And, of course, I love working with you. And I'm not the only one. The next episode, episode 24, will be recorded live on Wednesday, February 5th, at 10 am PST. And the guest will be Robert Haas, who is another Postgres major contributor and committer. And the topic will be "Why mentor Postgres developers?" So if you want to mark your calendar to be part of that live recording on Discord, aka.ms/talkingpostgres-ep24-cal will give you a good calendar invite. You can always get to past episodes and get links to subscribe on the different podcast platforms by going to talkingpostgres.com. And you'll find transcripts and show notes included for the episode pages for all the episodes. And we love it when people subscribe, and we love it when people recommend the show. And if you want to compliment us publicly, privately, that's all good too. If you have suggestions for future guests you can just DM me on one of those social platforms. The hashtag for this podcast is #TalkingPostgres. And word of mouth is one of the best ways to help people discover a podcast like this. A big thank you to everybody who joined the live recording on Discord. And thank you again to Daniel.
DANIEL: 01:21:57
Thank you.
