Re: pg_get__*_ddl consolidation
| От | Andrew Dunstan |
|---|---|
| Тема | Re: pg_get__*_ddl consolidation |
| Дата | |
| Msg-id | 93b0b82c-754d-4cc3-bec8-b0eb90410c35@dunslane.net обсуждение |
| Ответ на | Re: pg_get__*_ddl consolidation (Mahendra Singh Thalor <mahi6run@gmail.com>) |
| Список | pgsql-hackers |
On 2026-03-19 Th 4:28 PM, Mahendra Singh Thalor wrote: > On Fri, 20 Mar 2026 at 01:44, Andrew Dunstan <andrew@dunslane.net> wrote: >> >> You could construct these functions using plpgsql. The information isn't hidden from non-superusers. So what exactly wouldmaking these functions superuser-only achieve? Now it's true that the user might not be able to execute the DDL. Butthat's not the point. > Thanks Andrew for the clarification. > > Sorry, my question might be stupid. Can we use these functions > directly into our dump utilities so that common code can be removed > and if there is any syntax change for a particular object, then no > need to change into different-2 places, rather we just need to change > it into ddlutils.c file only. Well, we have tried to make the output like pg_dump. We might later provide options for more compact output. But it remains to be seen if it can be used in the pg_dump utilities. After all, it is going to produce output suitable for the source version, since there is no knowledge in the server of future versions. But pg_dump emits SQL suitable for the target version. My original motivation was quite different. It was to give the user a piece of SQL that they could modify as they saw fit, rather than making them start with a blank canvas. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: