add --stored-proc-type to choose PL/pgSQL vs C when building DB

[sahitya-chandra]

Summary

Implements #22: the database build path can choose whether stored functions are loaded as PL/pgSQL (default) or C, matching the clarified issue scope (implementation choice, not which individual procedures to install).

Earlier work on the same PR targeted “subset of the ten procedures”; that has been removed in favor of this simpler pass-through to the existing dbt5-pgsql-load-stored-procs -t behavior.

What changed

• dbt5-pgsql-build-db: New --stored-proc-type=TYPE with TYPE = plpgsql or c (default plpgsql). Passed to dbt5-pgsql-load-stored-procs as -t TYPE.
• dbt5 build: New --stored-proc-type=TYPE, forwarded to dbt5-pgsql-build-db.
• doc/postgresql.rst: Documents --stored-proc-type and that c requires C extensions built/installed on the server first.
• man/man1/dbt5-build.1.rst.in: Documents --stored-proc-type.

No changes to dbt5-pgsql-load-stored-procs logic; it already supports -t plpgsql|c.

Example

dbt5 build --tpcetools=/path/to/egen --stored-proc-type=c pgsql

Using c still requires a prior make / make install in storedproc/pgsql/c on the PostgreSQL server (same as loading manually with -t c).

Backward compatibility

Default remains PL/pgSQL; callers who omit the new flag behave as before.

[markwkm]

I like this idea. Might take me a little bit more time to look through it.

[markwkm]

I'm wondering if the compose environment I just added (38d6bbf) will be a nice way to play with this. I still need a little more time to try this more in depth.

As I think more about the build script pass through, I'm not sure about the use case for that. I feel that on an initial build, you always want everything. Otherwise you don't have a complete build, in other words the workload won't function if there is a stored function missing.

So the more I think out load, the more I'm starting to question if it's worth the extra code. It's pretty fast and a bit simpler to just reload everything all at once with the way the things work now.

While the finer control sounds nice, I'm wondering if it'll still be easier to not use it...

[markwkm]

I just realized this references #22. This actually doesn't do what I meant in #22. The build script should allow the user to picked whether pl/pgsql or C stored functions to be used. Not which of the stored functions to re/install.

I'll try to clarify in #22.

[sahitya-chandra]

I just realized this references #22. This actually doesn't do what I meant in #22. The build script should allow the user to picked whether pl/pgsql or C stored functions to be used. Not which of the stored functions to re/install.

I'll try to clarify in #22.

@markwkm sir, thanks for the detailed feedback and for updating #22
when the issue had no body, the title (“specify which stored functions/procedures to use”) sounded like which procedures to install or load (e.g. a subset of the TPC-E frames), not which implementation of those procedures (PL/pgSQL vs C). With an empty description, I went with that interpretation and implemented selective build/load for the ten procedure names

Corrected approach for #22 (PL/pgSQL vs C)

• Add a single option on the DB build path (e.g. dbt5 build / dbt5-pgsql-build-db) to choose stored-function implementation: plpgsql (default) or c.
• Pass that through to dbt5-pgsql-load-stored-procs as the existing -t flag (-t plpgsql / -t c) when the build script loads procedures - no need to reimplement loading logic.
• Docs / help: note that -t c only works if the C extensions are already built and installed on the server (same as today when loading manually).

I will revert the “subset of ten procedures” behavior from the PR and implement this instead. I am happy to discuss more on this

[markwkm]

I will revert the “subset of ten procedures” behavior from the PR and implement this instead. I am happy to discuss more on this

What will be more helpful for discussion is if you put the description of the changes into the commit too. It looks like you left the ability to select individual functions. Let's keep it simpler.

[markwkm]

Because I didn't write it here... #30 (comment)

[sahitya-chandra]

I will revert the “subset of ten procedures” behavior from the PR and implement this instead. I am happy to discuss more on this

What will be more helpful for discussion is if you put the description of the changes into the commit too. It looks like you left the ability to select individual functions. Let's keep it simpler.

Sure sir, I will follow exactly this in my next commit, with proper implementation. thanks

[sahitya-chandra]

@markwkm sir, I have pushed the changes with a proper commit message and also updated the pr title and description.

Let me know if you'd like any changes!
thanks

[markwkm]

I think this looks ok. I still need to try it.

One thing to note is that I don't use GitHub to managing the repo, so I'll probably remove references to issues and pull requests.

[sahitya-chandra]

No issues, sir. Is there anything you want me to test on my side?