Re: Behavior of PL/pgSQL function following drop and re-create of a table that it uses

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: Behavior of PL/pgSQL function following drop and re-create of a table that it uses
Дата
Msg-id CAKFQuwbx=xFMedvGBk99d9dLmNhu_KNC_LwknsWV1793qjWXLw@mail.gmail.com
обсуждение исходный текст
Ответ на Behavior of PL/pgSQL function following drop and re-create of a table that it uses  (Bryn Llewellyn <bryn@yugabyte.com>)
Ответы Re: Behavior of PL/pgSQL function following drop and re-create of a table that it uses
Список pgsql-general
(adding back the list)

On Tue, Mar 7, 2023 at 8:24 PM David G. Johnston <david.g.johnston@gmail.com> wrote:
On Tue, Mar 7, 2023 at 7:54 PM Bryn Llewellyn <bryn@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:


 /*
* 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.

В списке pgsql-general по дате отправления:

Предыдущее
От: Siddharth Jain
Дата:
Сообщение: could not bind IPv4 address "127.0.0.1": Address already in use
Следующее
От: "David G. Johnston"
Дата:
Сообщение: Fwd: Behavior of PL/pgSQL function following drop and re-create of a table that it uses