(adding back the list) On Tue, Mar 7, 2023 at 8:24 PM David G. Johnston <david.g.johns...@gmail.com> wrote:
> On Tue, Mar 7, 2023 at 7:54 PM Bryn Llewellyn <b...@yugabyte.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: https://github.com/postgres/postgres/blob/401874ab020b44d8000ac90debef43a146b96d5a/src/pl/plpgsql/src/pl_comp.c#L2180 /* * 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.
