Re: View to get all the extension control file details

Поиск
Список
Период
Сортировка
От Haribabu Kommi
Тема Re: View to get all the extension control file details
Дата
Msg-id CAJrrPGdyJ=a=Aqu6Uzz2CsFt+erzg4GH15SaYU6uUPYpqkaj1Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: View to get all the extension control file details  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: View to get all the extension control file details
Список pgsql-hackers
On Sat, Oct 13, 2018 at 3:57 AM Robert Haas <robertmhaas@gmail.com> wrote:
On Wed, Oct 10, 2018 at 8:27 AM Haribabu Kommi <kommi.haribabu@gmail.com> wrote:
> Here is the patch as per the above discussion.

One potential problem with this is that we could add more control-file
attributes in the future, and it will be annoying if the view ends up
with a million columns, or if we ever have to rename them.

Yes, there is a problem if we add more attributes or rename them.
 
  People who
have created objects that depend on those views may find that
pg_dump/restore or pg_upgrade fail, just as they do when we whack
around pg_stat_activity. pg_settings gets around that using an
EAV-like format.  I'm not sure that's the best solution here, but it's
something to think about.

similar like pg_settings view, so displaying all the data without validating
them from pg_extension may solve the problem.

Other idea to avoid this problem is, how about displaying the extra columns using JSONB
data type, so that all the extra additional columns that are not important
will go to that column?

Regards,
Haribabu Kommi
Fujitsu Australia

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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: [PATCH] heap_insert() and heap_update() optimization
Следующее
От: Victor Wagner
Дата:
Сообщение: Building 64-bit postgres with GSS support on windows