From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | Bryn Llewellyn <bryn(at)yugabyte(dot)com>, pgsql-general list <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Behavior of PL/pgSQL function following drop and re-create of a table that it uses |
Date: | 2023-03-08 04:25:01 |
Message-ID: | CAKFQuwbx=xFMedvGBk99d9dLmNhu_KNC_LwknsWV1793qjWXLw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
(adding back the list)
On Tue, Mar 7, 2023 at 8:24 PM David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>
wrote:
> On Tue, Mar 7, 2023 at 7:54 PM Bryn Llewellyn <bryn(at)yugabyte(dot)com> wrote:
>
>>
>>
> This is what I expected actually, though I can't point to exactly why.
>
>>
>> Where can I read what I need in order to understand the difference here,
>> using %rowtype, and in the first test that I posted, using %type?
>>
>
> I'm not certain there should be. Given the presence of the bug below and
> general infrequency of this scenario I wouldn't be totally surprised there
> is a bug here as well.
>
So I found where this difference in behavior is at least explicitly noted:
/*
* If it's a named composite type (or domain over one), find the typcache
* entry and record the current tupdesc ID, so we can detect changes
* (including drops). We don't currently support on-the-fly replacement
* of non-composite types, else we might want to do this for them too.
*/
If this limitation is documented in a user-facing manner I do not know
where.
David J.
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2023-03-08 04:26:38 | Fwd: Behavior of PL/pgSQL function following drop and re-create of a table that it uses |
Previous Message | Siddharth Jain | 2023-03-08 01:28:13 | could not bind IPv4 address "127.0.0.1": Address already in use |