proposal - reglanguage type
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t42014psql -h localhost -U postgresBuilt from patchset v1 (message #1), July 28, 2026 at 03:02 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t42014_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t42014_1 && git checkout t42014_1Patchset v1 (message #1) is on t42014_1
Hi
I miss a reglanguage type from our set of reg* types.
It reduce a mental overhead for queries over pg_proc table
With this type I can easy filter only plpgsql functions
select *
from pg_proc
where prolang = 'plpgsql'::reglanguage
and pronamespace <> 'pg_catalog'::regnamespace;
Regards
Pavel
Pavel Stehule <pavel.stehule@gmail.com> writes:
I miss a reglanguage type from our set of reg* types.
I'm skeptical about this. I don't think we want to wind up with a reg*
type for every system catalog, so there needs to be some rule about which
ones it's worth the trouble for. The original idea was to provide a reg*
type if the lookup rule would be anything more complicated than "select
oid from <catalog> where name = 'foo'". We went beyond that with
regnamespace and regrole, but I think there was a sufficient argument of
usefulness for those two. I don't see that reglanguage has enough of
a use-case.
regards, tom lane
ne 1. 3. 2020 v 19:31 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:
Pavel Stehule <pavel.stehule@gmail.com> writes:
I miss a reglanguage type from our set of reg* types.
I'm skeptical about this. I don't think we want to wind up with a reg*
type for every system catalog, so there needs to be some rule about which
ones it's worth the trouble for. The original idea was to provide a reg*
type if the lookup rule would be anything more complicated than "select
oid from <catalog> where name = 'foo'". We went beyond that with
regnamespace and regrole, but I think there was a sufficient argument of
usefulness for those two. I don't see that reglanguage has enough of
a use-case.
the use-case is probably only one - filtering pg_proc. Probably the most
common filter is
prolang = (SELECT oid
FROM pg_language
WHERE lanname = 'plpgsql')
It's little bit not comfortable so for namespace we can do pronamespace <>
'pg_catalog'::regnamespace and there is nothing for language.
This feature is interesting for people who write code in plpgsql, or who
migrate from PL/SQL (and for people who use plpgsql_check).
All mass check (mass usage of plpgsql_check) have to use filter on prolang.
Regards
Pavel
Show quoted text
regards, tom lane