incorrect error message, while dropping PROCEDURE
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:t37869psql -h localhost -U postgresBuilt from patchset v1 (message #1), July 27, 2026 at 09:41 PM.
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 t37869_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 t37869_1 && git checkout t37869_1Patchset v1 (message #1) is on t37869_1
Hi,
Currently if some one try to drop the PROCEDURE and
it don't have privilege or it's not an owner, than error message
still indicate object as FUNCTION.
Example:
postgres@37737=#drop procedure pro;
ERROR: must be owner of function pro
This doesn't look correct specially that now we have separate
object type as OBJECT_PROCEDURE. It seems like we need
to introduce new AclObjectKind for PROCEDURE and do the
necessary changes to pass the correct AclObjectKind.
PFA patch, where introduced new AclObjectKind (ACL_KIND_PROCEDURE),
msg for the new AclObjectKind, and passed it through at
appropriate places.
Also update the necessary "make check" expected output changes.
Regards,
Thanks,
Rushabh Lathia
www.EnterpriseDB.com
On 12/13/17 23:31, Rushabh Lathia wrote:
Currently if some one try to drop the PROCEDURE and
it don't have privilege or it's not an owner, than error message
still indicate object as FUNCTION.
Yes, that is actually something that is fixed by the patches proposed in
the thread "replace GrantObjectType with ObjectType".
PFA patch, where introduced new AclObjectKind (ACL_KIND_PROCEDURE),
msg for the new AclObjectKind, and passed it through at
appropriate places.
Yeah, that's a way to do it, but having both ACL_KIND_PROC and
ACL_KIND_PROCEDURE is clearly confusing. The above-mentioned patch
cleans that up more thoroughly, I think.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Fri, Dec 15, 2017 at 12:18 AM, Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
On 12/13/17 23:31, Rushabh Lathia wrote:
PFA patch, where introduced new AclObjectKind (ACL_KIND_PROCEDURE),
msg for the new AclObjectKind, and passed it through at
appropriate places.Yeah, that's a way to do it, but having both ACL_KIND_PROC and
ACL_KIND_PROCEDURE is clearly confusing. The above-mentioned patch
cleans that up more thoroughly, I think.
+1. I looked at the patch of Peter, as well as this one, and I prefer
Peter's approach of reducing duplications in concepts.
--
MichaelOn Fri, Dec 15, 2017 at 3:32 AM, Michael Paquier <michael.paquier@gmail.com>
wrote:
On Fri, Dec 15, 2017 at 12:18 AM, Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:On 12/13/17 23:31, Rushabh Lathia wrote:
PFA patch, where introduced new AclObjectKind (ACL_KIND_PROCEDURE),
msg for the new AclObjectKind, and passed it through at
appropriate places.Yeah, that's a way to do it, but having both ACL_KIND_PROC and
ACL_KIND_PROCEDURE is clearly confusing. The above-mentioned patch
cleans that up more thoroughly, I think.+1. I looked at the patch of Peter, as well as this one, and I prefer
Peter's approach of reducing duplications in concepts.
Yes, I also agree.
Thanks,
--
Rushabh Lathia