Hi,
Thank you very much, I'll check it out. It looks like the
getObjectIdentity() used in
pg_identify_object() could do.
--
Regards,
Nikita Malakhov
Postgres Professional
The Russian Postgres Company
https://postgrespro.ru/
On 2023-Oct-13, Nikita Malakhov wrote:
> Textual representation requires a long text field because it could
> contain schema, arguments, it is difficult and not effective to be
> saved as part of the data, and must be parsed to retrieve function
> oid.
It is worse than that: the regproc textual r
On Thu, 2023-10-12 at 19:56 +0300, Nikita Malakhov wrote:
> Say, we have data processed by some user function and we want to keep
> reference to this function
> in our data. In this case we have two ways - first - store string output of
> regprocedure, which is not
> very convenient, and the seco
On Thu, Oct 12, 2023 at 2:58 PM Nikita Malakhov wrote:
> Why pg_upgrade cannot be used?
>
We document both a pg_dump/pg_restore migration and a pg_upgrade one (not
to mention that logical backup and restore would cause the oids to
change). It seems odd to have a feature that requires pg_upgrade
Hi,
Textual representation requires a long text field because it could contain
schema,
arguments, it is difficult and not effective to be saved as part of the
data, and must
be parsed to retrieve function oid. By using direct oid (actually, a value
of the regprocedure field) we avoid it and functi
On Thu, Oct 12, 2023 at 1:31 PM Nikita Malakhov 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 interna
Hi,
I've already implemented preserving PG_PROC oids during pg_upgrade
in a way like relfilenodes, etc, actually, it is quite simple, and on the
first
look there are no any problems.
About using surrogate key - this feature is more for data generated by
the DBMS itself, i.e. data processed by som
On Thu, Oct 12, 2023 at 3:36 PM David G. Johnston
wrote:
> Every catalog has both a natural and a surrogate key. Developers get to use
> the surrogate key while end-users get to use the natural one (i.e., the one
> they provided). I see no reason to change that specification.
I agree with thi
On Thu, Oct 12, 2023 at 11:43 AM Robert Haas wrote:
> On Thu, Oct 12, 2023 at 2:38 PM David G. Johnston
> wrote:
> > It's more like a lot number or surveying tract than an postal address.
> Useful for a single party, the builder or the government, but not something
> you give out to other people
On Thu, Oct 12, 2023 at 2:38 PM David G. Johnston
wrote:
> It's more like a lot number or surveying tract than an postal address.
> Useful for a single party, the builder or the government, but not something
> you give out to other people so they can find you.
>
> Whether or not we copy over oi
On Thu, Oct 12, 2023, 11:21 Robert Haas wrote:
>
> The pg_upgrade experience right now is a bit as if you woke up in the
> morning and found that city officials came by during the night and
> renumbered your house, thus changing your address. Then, they sent
> change of address forms to everyone
On Thu, Oct 12, 2023 at 10:35 AM Tom Lane wrote:
> You have the burden of proof backwards. That would add a great deal
> of new mechanism, and you haven't provided even one reason why it'd
> be worth doing.
"A great deal of new mechanism" seems like a slight exaggeration. We
preserve a bunch of
On Thu, Oct 12, 2023 at 7:36 AM Tom Lane wrote:
> Nikita Malakhov writes:
> > Please advise on the idea of preserving pg_proc oids during pg_upgrade,
> in
> > a way like relfilenodes, type id and so on. What are possible downsides
> of
> > such a solution?
>
> You have the burden of proof backwa
On Thu, Oct 12, 2023 at 9:57 AM Nikita Malakhov wrote:
> Say, we have data processed by some user function and we want to keep
> reference to this function
> in our data.
>
Then you need to keep the user-visible identifier of said function
(schema+name+input argument types - you'd probably want
Hi!
Say, we have data processed by some user function and we want to keep
reference to this function
in our data. In this case we have two ways - first - store string output of
regprocedure, which is not
very convenient, and the second - store its OID, which requires slight
modification of pg_upgr
Nikita Malakhov writes:
> Please advise on the idea of preserving pg_proc oids during pg_upgrade, in
> a way like relfilenodes, type id and so on. What are possible downsides of
> such a solution?
You have the burden of proof backwards. That would add a great deal
of new mechanism, and you haven
Hi hackers!
Please advise on the idea of preserving pg_proc oids during pg_upgrade, in
a way like relfilenodes, type id and so on. What are possible downsides of
such a solution?
Thanks!
--
Regards,
Nikita Malakhov
Postgres Professional
The Russian Postgres Company
https://postgrespro.ru/
17 matches
Mail list logo
