From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | Nikita Malakhov <hukutoc(at)gmail(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Pro et contra of preserving pg_proc oids during pg_upgrade |
Date: | 2023-10-12 21:46:41 |
Message-ID: | CAKFQuwbfxjt6YjkCm0PDp+q+7gMhYPCs5sGsA7cRhELRk92Trg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Oct 12, 2023 at 1:31 PM Nikita Malakhov <hukutoc(at)gmail(dot)com> wrote:
> About using surrogate key - this feature is more for data generated by
> the DBMS itself, i.e. data processed by some extension and saved
> and re-processed automatically or by user's request, but without bothering
> user with these internal keys.
>
Then what does it matter whether you spell it:
12345
or
my_ext.do_something(int)
?
Why do you require us to redefine the scope for which pg_proc.oid is useful
in order to implement this behavior?
Your extension breaks if your user uses logical backups or we otherwise
get into a position where pg_upgrade cannot be used to migrate in the
future. Is avoiding the textual representation so necessary that you need
to add another dependency to the system? That just seems unwise regardless
of how easy it may be to accomplish.
David J.
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2023-10-12 21:52:38 | Re: [PATCH] Clarify the behavior of the system when approaching XID wraparound |
Previous Message | Nikita Malakhov | 2023-10-12 20:30:53 | Re: Pro et contra of preserving pg_proc oids during pg_upgrade |