| From: | Bear Giles <bgiles(at)coyotesong(dot)com> |
|---|---|
| To: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Proposed: extend github pages for documentation's sample code |
| Date: | 2026-01-29 16:25:26 |
| Message-ID: | CALBNtw4gv20zapZfbjKbX1m_LojD8NH5xm=r0DQj=BNBi5j5Pg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
I've been working on a new page or two of documentation of libpq. It's
mostly aimed towards zero-trust concerns - exposing a few methods already
present in fe-connect and documenting them. I'll have more details later.
For now I wanted to call out that (at least) one code sample fails to
compile. Lord knows I've done that with my own blog in the past - distant
-ast - because I was focused on conveying the concepts. But it's now easy
to directly include source files into documentation so it makes sense to
have working and tested code in the documentation.
The natural place to put this is the rest of the project's source code, but
in a separate area that allows the reader to build the example without all
of the dependencies of the parent project. In my current POC I'm using
meson, like the full project, but the only external dependency is on libpq.
I'll obviously need to add a few more dependencies when I add examples with
SSL, OAuth, and GSSAPI, but it will always be far fewer dependencies than
the parent project.
So where should the example code go?
Bear
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2026-01-29 16:27:30 | Re: pg_stat_io_histogram |
| Previous Message | Tom Lane | 2026-01-29 16:23:59 | Re: getting "shell command argument contains a newline or carriage return:" error with pg_dumpall when db name have new line in double quote |