Now is the time to work on getting together a strong set of projects we’d like to have GSoC contributors work on over the summer. Like previous years, we must have an excellent Ideas list ready before the deadline for mentoring organizations. This list is the primary criterion Google uses to evaluate and accept us into the program.

The deadline for Mentoring organizations to apply is February 3, 2026 at 18:00 UTC. The list of accepted organizations will be published on February 19. Here’s the complete timeline for your planning:

GSoC 2026 Timeline:

• January 19: Organization Applications Open
• February 3 (18:00 UTC): Deadline for Organization Applications
• February 19: Accepted Organizations Announced
• March 16 – 31: Contributor Application Period
• April 2: Deadline for Final Proposals
• May 4: Community Bonding Begins

I’ve already created our GSoC 2026 Ideas page as our central hub for project submissions. The quality of this Ideas list will define the tone of our participation this year, so let’s make it outstanding!

What Makes a Great Project Idea?

Each project on our Ideas page should include these essential elements:

1. Project Title and Description (2-5 sentences that clearly explain the project)
2. Expected Outcomes (what will be delivered)
3. Required/Preferred Skills (programming languages, technologies, domain knowledge)
4. A potential mentor (two mentors are highly recommended)
5. Project Size: Small (90 hours), Medium (175 hours), or Large (350 hours)
6. Difficulty Rating: Easy, Medium, or Hard

Critical Guidelines to Remember:

Never link to just a bug tracker as your project description. This leads to automatic rejection by Google. Keep descriptions high-level enough to allow contributor creativity, but avoid being vague. We want to inspire innovation while providing clear direction.

We’re aiming for a diverse mix of projects including “Low-hanging fruit” for newcomers, “Core development” challenges for experienced contributors, and “Infrastructure” improvements that benefit the entire ecosystem.

PostgreSQL as an Umbrella Project

As with previous years, please consider PostgreSQL to be an “Umbrella” project. Anything that would be regarded as part of the “PostgreSQL Family” per our News/Announce policy is likely to be acceptable as a PostgreSQL GSoC project.

This means if you’re a contributor or developer working on patroni, WAL-G, barman, pgBackRest, pgwatch, pgagroal, pgexporter, pgmoneta, pgpool, pgbouncer, the PostgreSQL website (pgweb), pgAdmin4, DBeaver, HeidiSQL, pldebugger, pspg, the JDBC driver, the ODBC driver, or any of the many other PostgreSQL Family projects, please feel free to add a project for consideration!

How You Can Help

Having at least two mentors per project is not just recommended but essential to decrease the individual load and provide better support to our contributors. Please consider listing yourself as a co-mentor for projects with only one mentor listed.

If you have ideas from previous years that are still relevant, update them for 2026. Make sure to revise all the information, particularly listing yourself as a mentor and updating the project scope to be reasonable for the time contributors are given.

New entries are absolutely welcome and encouraged! Projects from last year that were worked on but had significant follow-on work to be completed are also welcome just update the description appropriately.

Remember Our Greater Mission

The program’s goals extend far beyond code writing. One of our primary objectives is to inspire new developers to begin participating in open-source communities and help open-source projects identify and bring in new long-term contributors. Every mentor interaction is an opportunity to welcome someone into our wonderful PostgreSQL community.

When we get closer to submitting our application, I’ll clean out any outdated entries that haven’t received updates. If any projects are no longer appropriate because they were completed independently, please feel free to remove them.

Let’s make GSoC 2026 another fantastic year for PostgreSQL and our entire ecosystem! Your participation as mentors and project contributors is what makes this program successful year after year.

PGForce be with you!

Best regards,
Pavlo Golub,
on behalf of PostgreSQL GSoC Admins 💙💛

Back in May, I welcomed these talented people to our community. Now, six months later, I’m proud to celebrate not just the code they wrote, but the journey they made and the community members they’ve become.

A Year Like No Other

This year’s GSoC was something special. We received 213 applications for the PostgreSQL organization alone—the highest number in our 21 years of participating in GSoC! But with this big number came challenges: a lot of spam and AI-generated applications made the selection process very difficult. We requested 9 project slots, but received only 7 because of program-wide limitations.

But from those 213 applications, we found seven great people who achieved a 100% success rate. Not a single contributor failed to complete their project. Think about that for a moment. 💯

The Human Story Behind the Code

What I like most about this year’s group isn’t just the great technical work—though there was a lot of it. It’s the personal growth, the determination, and the way each contributor became part of something bigger than themselves.

Let me introduce you to our seven successful contributors and their remarkable journeys:

Ashutosh Sharma worked on the difficult task of implementing incremental backup for PostgreSQL 13-16 in pgmoneta. So during the course of this program, he implemented an infrastructure that perform block-level incremental backups in pgmoneta for PostgreSQL versions 13‑16!

Mohab Yasser created pgmoneta-walfilter, a tool for precise WAL stream manipulation. His words say something important: “This project provided deep exposure to PostgreSQL internals… Reading through PostgreSQL source code to understand WAL record formats was challenging but instructive.” This is what GSoC is about—not just writing code, but becoming an expert in the process.

Tejas Tyagi worked on pgagroal security improvements and described the GSoC experience very well: “This experience has given me the confidence that I can work on and contribute to large, production-grade systems. I had no prior experience with connection poolers or many of the technologies I worked with, but through this project, I’ve developed skills that will serve me throughout my career.”

Bassam Adnan added extension support to pgexporter, implementing metrics for 15+ PostgreSQL extensions. His work on semantic versioning, HTTP API refactoring, and comprehensive testing demonstrates how one project can touch multiple areas and benefit multiple related projects.

Gaurav Patidar modernized pgwatch’s Grafana dashboards for v12. His systematic approach—creating Python scripts to detect deprecated components, then carefully refining each panel—shows the maturity needed for maintenance work that keeps projects accessible to users.

Mankirat Singh built an ABI compliance checker that now runs as “Baza” on the PostgreSQL BuildFarm. His journey from commit-by-commit checking to tag-based comparison, guided by community feedback, illustrates how GSoC teaches contributors to listen, adapt, and align with project needs.

Ahmad Gouda enhanced pgwatch’s RPC integration, migrating from basic Go RPC to gRPC and implementing new sinks for ElasticSearch, Google Cloud pub/sub, and Apache Iceberg. His work shipped with pgwatch v4, demonstrating real-world impact.

Beyond the Technical Achievements

The beauty of GSoC isn’t just in the code—it’s in the transformation of individuals into community members. Let me share what I observed:

Community Bonding That Actually Bonded

Ahmad’s experience shows this very well. He found the PostgreSQL Hacking Discord channel and started attending monthly Hacking Workshops. He contributed to pg_duckdb, adding SQLSmith CI tests. He didn’t just work on his assigned project—he became part of the ecosystem.

Several contributors attended conferences during or after their GSoC period. They presented their work, networked with other community members, and began building the relationships that sustain long-term contributions.

The Debugging Stories

Some of my favorite moments were the “deep dive” debugging sessions:

• Mohab adding debug prints to PostgreSQL source code to understand WAL parsing and discovering that the issue wasn’t in decode_xlog_record but in how pgmoneta_wal_parse_wal_file calculated offsets
• Tejas tackling transaction pipeline bugs that only manifested with specific IO backends
• Mankirat learning Perl (a language he’d never used!) to write BuildFarm client modules

These aren’t just technical challenges—they’re experiences that build character and create confident, capable contributors.

Learning New Languages and Frameworks

Look at the diversity of technologies our contributors mastered:

• Mankirat learned Perl and CGI server setup
• Bassam worked extensively with C, HTTP protocols, and memory management
• Ahmad migrated systems from basic RPC to gRPC
• Tejas deep-dived into TLS/SSL protocols and certificate management

Each contributor stepped outside their comfort zone, proving that passion and persistence matter more than prior expertise.

What Makes a Successful GSoC Experience?

Looking at this year’s group, I see several patterns:

Communication: Every successful contributor engaged actively—on GitHub discussions, mailing lists, Discord channels. They asked questions, provided updates, and sought feedback early and often.

Adaptability: Mankirat’s pivot from commit-by-commit to tag-based comparison, Ahmad’s migration to gRPC after discovering limitations in Go’s RPC—these weren’t failures, they were smart pivots based on community feedback.

Ownership: These contributors didn’t just implement features—they fixed bugs they encountered, improved documentation, and thought about long-term maintainability.

Community Integration: The best contributors didn’t work in isolation. They reviewed each other’s code, discussed approaches, and celebrated each other’s successes.

The Mentor’s Perspective

I want to share something that mentors often don’t say in public: we learn as much from contributors as they learn from us.

This year’s contributors gave us fresh perspectives. They asked “why?” when we thought something was obvious. They suggested solutions we hadn’t thought about. They brought energy and enthusiasm that gave new life to projects.

Several of this year’s mentors are GSoC alumni from previous years. This beautiful cycle—yesterday’s contributors becoming today’s mentors—is the lifeblood of our community.

The Numbers

While this post talks about the journey, let’s not forget the real impact:

• 7 contributors, all successful! 💯
• 30+ pull requests merged across multiple projects
• Code in production releases (pgwatch, pgmoneta, pgagroal, pgexporter)
• Work in C, Go, Python, Perl, Rust
• Projects from backup systems to security improvements to monitoring tools

But these numbers tell only part of the story. Each line of code represents hours of learning, debugging, and growth.

Challenges We Faced

This year had its problems. We faced:

• The biggest number of applications ever (213 for PostgreSQL alone!)
• A lot of spam and AI-generated applications
• Fewer slots than we wanted (7 instead of 9)
• Difficult coordination across distributed teams

But every contributor kept going, showing great determination and adaptability.

A Call to Action: We Need You!

Here’s my most important message: we need more mentors!

The problem isn’t talented contributors—we had 213 applications this year! The problem is we don’t have enough mentors. The more mentors we have, the more projects we can support, the more contributors we can welcome, the stronger our community becomes.

If you’re an experienced PostgreSQL community member, consider becoming a mentor. You don’t need to be a core developer. You need:

• Experience with PostgreSQL and related tools
• Time to dedicate during the summer
• Patience and love for teaching
• Care for the community

Mentoring is incredibly rewarding. You’ll:

• Shape the next generation of PostgreSQL contributors
• Learn from fresh perspectives
• Strengthen the ecosystem
• Make lasting connections

Interested? Reach out to me or join our discussions on the mailing lists!

Special Thanks

A special acknowledgment to Jesper Pedersen, my co-admin for the GSoC program. It would be unreal to handle all this work without him! Jesper’s dedication, organizational skills, and mentorship across multiple projects were instrumental to our success.

Thanks also to all the mentors who dedicated countless hours:

• Akshat Jaimini,
• Haoran Zhang,
• Saurav Pal,
• Rajiv Harlalka,
• David Wheeler,
• Luca Ferrari,
• Shahryar Soltanpour.

And to the broader community who welcomed our contributors, answered questions, reviewed code, and provided encouragement—thank you!

Looking Forward

These seven contributors aren’t finished with PostgreSQL—they’re just getting started. Several have already expressed interest in continuing their work, attending conferences, and becoming long-term community members.

Some of this year’s mentors are GSoC alumni from previous years, showing the beautiful cycle: yesterday’s contributors become today’s mentors, who help tomorrow’s contributors.

Final Thoughts

GSoC 2025 wasn’t just about code merged and features shipped. It was about:

• Building confidence in young developers
• Growing a welcoming, inclusive community
• Showing PostgreSQL’s commitment to education
• Making paths for new people to contribute

To our seven successful contributors: Congratulations! You’ve proven yourselves. You’ve shipped real code. You’ve joined a global community. You should be incredibly proud.

To everyone reading this: If you’re inspired by these stories, if you want to contribute, if you see yourself in these projects—come join us! The PostgreSQL community welcomes you with open arms.

Until next year’s GSoC, happy Postgres-ing! 💙💛

I encourage you to welcome contributors during these first weeks to get them excited and invested in our community. You will meet them on mailing lists, Slack, Discord, and other media.

The table below details information about this year’s project, contributors, and mentors!

We expect GSoC contributors to actively participate in the Community Bonding period from May 8th to June 1st. This period’s goal is to prepare contributors to begin their project work effectively on June 2nd. So please help them accommodate.

It was an insane start to the year! The GSoC program had the highest number of proposals ever, as well as the highest number of spam and AI-generated applications. Due to the high volume of new organizations and applications for the first time, on my memory, the PostgreSQL organization got only seven project slots out of 9!

This year, there were 213 total applications to PostgreSQL org only (sic!), the highest number we’ve had in 21 years of #GSoC! I really appreciate the hard work of our mentors, especially those whose projects weren’t accepted this year. Also, I am glad and proud at the same time because several of this year’s mentors are GSoC alumni of previous years! Kudos to everyone and all of us!

At the same time, I’m thankful to all the applicants who have spent their precious time! Please remember that despite not being part of the GSoC program this year, you are more than welcome in the PostgreSQL community! As a community, we will do our best to help you become a part of it.

Join Us as a GSoC Contributor

If you’re passionate about open-source development and eager to work on PostgreSQL projects, here’s how you can get involved:

• Application Period: 🗓️ March 24 - April 8, 2025

• Steps to Apply:
  1. Explore Our Project Ideas: Visit our GSoC wiki page to find project ideas that align with your interests and skills.
  2. Connect with Us: Reach out through our preferred communication channels to discuss project ideas and ask questions.
  3. Prepare Your Proposal: Use the insights from your interactions to craft a strong project proposal.
• Resources:
  • Introduction to GSoC Video
  • Contributor Guide
  • Advice for Applying to GSoC

Upcoming Info Session

To assist prospective contributors, GSoC team will be hosting an information session on Thursday, March 6, 16:00 UTC. Join the talk here!

Let’s Make 2025 a Milestone Year!

Building on the success of previous years, we are eager to welcome a diverse group of contributors to the PostgreSQL community. Whether you’re a student or a beginner in open-source development, GSoC 2025 is a fantastic opportunity to gain real-world experience and make meaningful contributions.

Stay tuned for more updates, and let’s make this year unforgettable!

For more details, visit the official GSoC announcement.

🚀 Let’s code, collaborate, and innovate together!

FOSDEM has long been a key event for the PostgreSQL community, and 2025 was no exception. Every year, PostgreSQL developers, contributors, and users worldwide gather in Brussels for a week packed with talks, meetings, and discussions. Our community has a strong tradition at FOSDEM, with a dedicated developer room, a booth, and numerous side events

One of the most recognizable FOSDEM traditions is FOSDEM Weather — a perfect mix of rain, cold, and clouds that always greets us in Brussels. Over the years, we even started selling PostgreSQL-branded umbrellas at our booth, and you could track the weather by watching the sales spike! But this year, for the first time in a while, the weather was sunny and perfect — so we joked that the weather was trying to lower our sales. 😄

A Busy Week for PostgreSQL

FOSDEM week is always busy for the PostgreSQL community, with multiple events happening alongside the main conference:

P2D2 Conference

Held earlier in the week, the Prague PostgreSQL Developer Day (P2D2) is a major PostgreSQL event that gathers experts for in-depth discussions. For a detailed experience of the event, check out Ants Aasma’s blog post.

PostgreSQL Developer Meeting

On Thursday, January 30th, PostgreSQL core developers and contributors held a private developer meeting to discuss ongoing projects, significant challenges, and future PostgreSQL development. More details can be found on the official event page.

FOSDEM PGDay

On Friday, January 31st, we had FOSDEM PGDay, a full-day PostgreSQL conference. The schedule featured talks on a wide range of PostgreSQL topics, from performance tuning to backups and new features. The complete schedule is available here.

PostgreSQL Devroom at FOSDEM

The PostgreSQL Devroom took place on Sunday, February 2nd, featuring sessions on database performance, replication, analytics, AI/ML, and more. This year, we had great discussions about PostgreSQL internals, best practices, and real-world use cases. You can find the complete session list here. The talk records will be available shortly.

Community & Networking

FOSDEM is not just about talks—it’s about meeting people, sharing ideas, and strengthening the community. As usual, there were plenty of social events and informal gatherings.

One of the highlights for me was attending the Google Summer of Code (GSoC) event on Saturday evening, where I had the chance to meet new and long-time friends. GSoC continues to be an essential program for PostgreSQL, and it was great to see the enthusiasm for mentoring and open-source contributions. Right now, PostgreSQL org is gathering project ideas and mentors. If you want to be a mentor, you still have time until February 10th!

Contributions & Recognition

This year’s central topic of discussion was contributions: what counts as a contribution, how we measure it, and how we recognize non-code contributions. Our community relies on the work of many people beyond just developers: event organizers, documentation writers, speakers, translators, and advocates all play a massive role in making PostgreSQL what it is today.

To help highlight and recognize these contributions, we put a lot of effort into building our new website: postgres-contrib.org. This platform helps track contributions and provides a way to nominate and recognize those who support the community.

Closing Thoughts

The spirit of the PostgreSQL community is what makes FOSDEM so special every year. I want to extend my huge thanks to all the volunteers, organizers, and contributors who made this event possible.

Special thanks to:

• The Call for Papers team (which I was part of) for reviewing and selecting the talks.
• All speakers who shared their knowledge.
• The attendees who made the devroom lively and interactive.

A special shoutout to volunteers, both scheduled and spontaneous. While we had a volunteer schedule for the booth, many community members stepped up to help when needed. For example, Bruce Momjian spent hours assisting visitors at the booth, helping find PostgreSQL T-shirts and hoodies in the correct sizes. And Ants Aasma helped a team of bouncers (well, pg bouncers, if you know what I mean ;) ). Many others did the same, proving once again that our community is built on collaboration and generosity.

We had a fantastic time at FOSDEM 2025, and I can’t wait to do it all again next year!

Until then, keep contributing and keep the PostgreSQL spirit alive! 🚀

Google Summer of Code 2025 is here, and PostgreSQL is once again proud to participate in this amazing program! Over the years, many talented contributors have started their PostgreSQL journey through GSoC, with some becoming long-term members of our community. Their commitment has helped improve PostgreSQL and its ecosystem, making this program an essential part of our growth and innovation.

Looking ahead, we are excited for new ideas, fresh contributors, and more diversity in projects, mentors, and mentees. PostgreSQL welcomes everyone who wants to contribute and learn, and we encourage both new and experienced community members to get involved.

What’s New for GSoC 2025?

This year, the GSoC team is particularly looking to support more security and AI/ML projects. If you know of an AI/ML or security-focused open-source project, encourage them to apply for GSoC 2025!

Who Can Participate?

GSoC is open to students and newcomers to open-source development, making it an excellent opportunity for those looking to get involved with PostgreSQL. Whether you’re interested in database internals, extensions, drivers, performance tools, or UI development, there’s a place for you in the PostgreSQL ecosystem.

Key Dates:

• Mentoring organization applications are open now at g.co/gsoc and close February 11, 2025, at 18:00 UTC.
• If you’re interested in becoming a mentor, now is the time to reach out to us!
• It’s time to collect project ideas and update the GSoC 2025 Ideas page.
• Read the GSoC Mentor Guide for useful tips.

Project Ideas and Mentorship

The most important part of our application as a mentoring organization is having a well-defined list of project ideas. These projects should take approximately:

• 90 hours (small project),
• 175 hours (medium project),
• 350 hours (large project).

We encourage all PostgreSQL community members to submit project ideas and volunteer as mentors. Mentorship is essential for growing our community, sharing knowledge, and integrating new contributors into PostgreSQL development.

Meet Us at FOSDEM

Want to discuss project ideas or mentorship opportunities in person?
Let’s talk during FOSDEM this week! PostgreSQL will have a booth and a devroom, so there will be plenty of opportunities to connect.

Also, a few members of the Google Open Source team will be at FOSDEM carrying GSoC pennant flags and blue GSoC beanies. You can find them:

• Upper level of Building K, near the large glass doors
• Saturday & Sunday from 11:00–14:00

Stop by and say hi if you’re interested in GSoC!

Apply Now & Spread the Word

As with last year, please consider PostgreSQL to be an “Umbrella” project, and anything that would be regarded as a “PostgreSQL Family” per the News/Announce policy is likely to be acceptable as a PostgreSQL GSoC project.

In other words, if you’re a contributor or developer on WAL-G, barman, pgBackRest, pgwatch, pgagroal, pgexporter, pgmoneta, pgpool, pgbouncer, the PostgreSQL website (pgweb), the PgEU/PgUS website code (pgeu-system), pgAdmin4, DBeaver, HeidiSQL, pldebugger, pspg, the PG RPMs (pgrpms), the JDBC driver, the ODBC driver, or any of the many other PG Family projects, please feel free to add a project for consideration!

We need:

• Project ideas that fit the GSoC guidelines.
• Mentors to help guide contributors.
• New contributors looking to get involved.
• Community support to spread awareness.

Next Steps

• Read the GSoC Mentor Guide and FAQs.
• Encourage other open-source projects to apply! If you know of an open-source org that might be a good fit, remind them to check out the GSoC resources and use us as a reference.

Let’s make GSoC 2025 another successful year for PostgreSQL and open-source innovation! 🚀

Best regards,
Pavlo Golub,
on behalf of PostgreSQL GSoC Admins 💙💛

He decided not to publish a video record of his talk for obvious reasons. But now, he has shared the essential details of his talk in the form of a blog article. I want to boost this blog post for all Planet Postgres readers; that’s the primary purpose of the text you’re reading.

Taras’s article discusses the importance of geoanalytics in military operations due to the prevalence of geospatial data, focusing on utilizing PostgreSQL to process such data. It addresses everyday geoanalytical tasks such as finding K-nearest objects, distance calculations, and point within a polygon determination. It aims to provide practical examples and tips. Open-source data, specifically russian military facility data from OpenStreetMap, is used as a primary dataset. It is then imported into PostgreSQL using the osm2pgsql tool for analysis and optimization.

Additionally, fire data from NASA satellites is introduced as a second data source, sourced from the Fire Information for Resource Management System (FIRMS). FIRMS allows real-time monitoring of active fires worldwide, including within russian military facilities’ territory since 2022. The process involves downloading fire data using a specific script and importing it into a PostgreSQL database for further analysis.

For example, the text outlines a task of finding the K-nearest neighbors, precisely ten fires near the Shahed production plant in russia, known for manufacturing Iranian Shahed drones. It refers to previous research by the Molfar team for detailed information about the factory, located in the special economic zone Alabuga in Tatarstan. The text highlights the shift in factory priorities towards drone production following sanctions. It proposes a method involving creating a buffer around the target area and recursively expanding it until the desired results are obtained.

Please, read and share! Glory to Ukraine! 💙💛

What are Batches?

Batch queries in pgx are a way of bundling multiple queries together to avoid unnecessary network round trips. A Batch must only be sent once. One can define a function to deal with the results of every query, e.g.

batch := &pgx.Batch{}
  batch.Queue("select some_func()").QueryRow(func(row pgx.Row) error {
    var n int32
    err := row.Scan(&n)
    if err != nil {
      return err
    }
    fmt.Println(n)
    return err
  })

  batch.Queue("select * from foo*").Query(func(rows pgx.Rows) error {
    // ...
  })

  batch.Queue("update foo set bar = 'zoo' where id = 1").Exec(func(ct pgconn.CommandTag) (err error) {
    if ct.RowsAffected() != 1 {
      err = errors.New("expected 1 row to be affected")
    }
    return
  })

  err = conn.SendBatch(ctx, batch).Close()

If a developer wants to have more control over result checking, they can use explicit way. This way the example above transforms to

  batch := &pgx.Batch{}
  batch.Queue("select some_func()")
  batch.Queue("select * from foo*")
  batch.Queue("update foo set bar = 'zoo' where id = 1")
  br := mock.SendBatch(ctx, batch)

  // process results
  var n int32
  err := br.QueryRow().Scan(&n)
  if err != nil {
    panic(err)
  }
  fmt.Println(n)

  rows, err := br.Query()
  if err != nil {
    panic(err)
  }
  // ... process rows here

  ct, err := br.Exec()
  if err != nil {
    panic(err)
  }
  if !ct.Update() || 1 == ct.RowsAffected() {
    fmt.Println("something bad happened")
  }

  err := br.Close()
  if err != nil {
    panic(err)
  }

And how am I supposed to test batches with pgxmock?

Really simple. Just as everything else. First, you define you expectations! Second, you call your function with a mock as an argument! And finally, you check if all expectations were met and if your code reacted as expected.

Let’s imagine we have a function to test

func processBatch(db pgx.Tx) err {
  batch := &pgx.Batch{}
  batch.Queue("select 1 + 1").QueryRow(func(row pgx.Row) error {
    var n int32
    return row.Scan(&n)
  })
  batch.Queue("update users set active = $1 where id = $2", true, 1).Exec(func(ct pgconn.CommandTag) (err error) {
    if ct.RowsAffected() != 1 {
      err = errors.New("expected 1 row to be affected")
    }
    return
  })
  return db.SendBatch(ctx, batch).Close()
}

func TestBatch(t *testing.T) {
  t.Parallel()
  mock, _ := NewConn()
  a := assert.New(t)

  // define our expectations
  eb := mock.ExpectBatch()
  eb.ExpectQuery("select").WillReturnRows(NewRows([]string{"sum"}).AddRow(2))
  eb.ExpectExec("update").WithArgs(true, 1).WillReturnResult(NewResult("UPDATE", 1))

  // run the test
  err := processBatch(mock)

  // check our expectations and code behaviour
  a.NoError(err)
  a.NoError(mock.ExpectationsWereMet())
}

Check pgxmock test cases to know more!

What about Prepare and Deallocate?

Since pgx doesn’t have a special struct to handle prepared statements, I simplified the ExpectPrepare struct in pgxmock. Instead of this

  mock.ExpectPrepare("articles_stmt", "SELECT (.+) FROM articles WHERE id = ?").
    ExpectQuery().
    WithArgs(1).
    WillReturnRows(NewRows([]string{"id", "title"}).AddRow(1, "Betty B."))

one will just use this

  mock.ExpectPrepare("authors_stmt", "SELECT (.+) FROM authors WHERE id = ?")
  mock.ExpectQuery("authors_stmt").
    WithArgs(1).
    WillReturnRows(NewRows([]string{"id", "title"}).AddRow(1, "Betty B."))

Pretty simple, huh?

Ready to Upgrade?

I motivate all users to upgrade to pgxmock v4 to take advantage of these exciting enhancements and improvements. Whether you’re a long-time user or just starting with pgxmock, these changes will advance your PostgreSQL mocking experience.

To get started with pgxmock v4, check your import statement:

import "github.com/pashagolub/pgxmock/v4"

and/or run

go get -u github.com/pashagolub/pgxmock/v4

Thank you for your continued support and feedback. I look forward to seeing how pgxmock v4 empowers your PostgreSQL database testing. If you have any questions or need assistance with the upgrade, please contact me on GitHub.

Happy mocking!

Please, read and share! Glory to Ukraine! 💙💛

And please make yourself familiar with the GSoC 2024 timeline!

Now is the time to work on getting together a set of projects we’d like to have GSoC students work on over the summer. Like last year, we must have a good set of projects for students to choose from before the deadline for mentoring organizations.

The deadline for Mentoring organizations to apply is February 6. The list of accepted organizations will be published on February 21.

Unsurprisingly, we’ll need to have an Ideas page again, so I’ve gone ahead and created one (copying last year’s).

Google discusses what makes a good “Ideas” list here.

All the entries are marked with ‘2023’ to indicate they were pulled from last year. If the project from last year is still relevant, please update it to ‘2024’. Make sure to revise all the information (in particular, list yourself as a mentor and remove the other mentors, as appropriate). Please also update the project’s scope to be reasonable for the time students are asked.

Having at least two mentors per project is an excellent idea to decrease the load. Please consider listing yourself as a co-mentor for projects with only one mentor listed. The program’s goals are not limited solely to code writing. One of the goals is to inspire new developers to begin participating in open-source communities and to help open-source projects identify and bring in new developers.

New entries are welcome and encouraged; note them as ‘2024’ when you add them.

Projects from last year that were worked on but had significant follow-on work to be completed are also welcome - update the description appropriately and mark it as being for ‘2024’.

When we get closer to submitting our application, I’ll clean out the ‘2023’ entries that have yet to receive any updates. Also, if any projects are no longer appropriate (maybe they were completed, for example, and no longer need work), please feel free to remove them. We may have missed some updates where a GSoC project was achieved independently of GSoC.

As a reminder, each idea on the page should be in the format that the other entries are in and should include:

1. Project Description
2. Skills needed
3. Difficulty Level
4. Project Size
5. Potential Mentors
6. Expected Outcomes
7. References

As with last year, please consider PostgreSQL to be an “Umbrella” project, and anything that would be regarded as a “PostgreSQL Family” per the News/Announce policy is likely to be acceptable as a PostgreSQL GSoC project.

In other words, if you’re a contributor or developer on WAL-G, barman, pgBackRest, pgwatch, pgagroal, pgexporter, pgmoneta, pgpool, pgbouncer, the PostgreSQL website (pgweb), the PgEU/PgUS website code (pgeu-system), pgAdmin4, DBeaver, HeidiSQL, pldebugger, pspg, the PG RPMs (pgrpms), the JDBC driver, the ODBC driver, or any of the many other PG Family projects, please feel free to add a project for consideration!

Let’s have another great year of GSoC with PostgreSQL!
PGForce be with you!

Best regards,
Pavlo Golub,
on behalf of PostgreSQL GSoC Admins 💙💛

What are the essential properties of such posts? These “posts” are short, contain external links, and without any meaningful supplement.

1. Planet PostgreSQL is not a microblog aggregator. I’m sure there is no place for one-sentence postings in the feed. Twitter, Bluesky, and Mastodon are all great places to go. No one will allow me to add my Mastodon RSS feed to the Planet.

2. Planet PostgreSQL is not a place for gateway pages - also known as doorway pages. The only purpose of such posts is to rank for particular search queries without offering helpful information. Instead, these micro-posts will redirect the reader to a different page.

3. Planet PostgreSQL is not a place for a black SEO. Planet PostgreSQL is a subdomain of a high-ranked postgresql.org. This fact makes the Planet page a perfect place to have as many links to your blog/company site as possible. Posting a lot of meaningless micro-posts will:

• Put and keep the author’s name in the “Top posters” section with a link;
• Put and keep the author’s company in the “Top Teams” section with a link;
• Put and keep links to micro-posts on the main postgresql.org page.
  

1. Planet PostgreSQL is a place for fair play. As a blog writer, I want to be in the same conditions as everyone else, regardless of the name, status, or previous achievements.

2. Planet PostgreSQL is a place for diversity and inclusion. First, I see it as an entry into the world of PostgreSQL — the area where one follows the heartbeat of the community. Good-written and interesting stories serve that purpose. Micro-posts with a link in it don’t. Second, I see it as a workshop where all authors from competitive companies work together to set a high bar for quality content. Micro-posts are not good and cannot be called content, frankly speaking.

Truly yours,
Pavlo Golub
Planet Macro-Poster 💙💛