Re: [HACKERS] pg_get_object_address() doesn't support composites
От | Alvaro Herrera |
---|---|
Тема | Re: [HACKERS] pg_get_object_address() doesn't support composites |
Дата | |
Msg-id | 20170218035307.fhusfixunonl4q5m@alvherre.pgsql обсуждение исходный текст |
Ответ на | [HACKERS] pg_get_object_address() doesn't support composites (Jim Nasby <Jim.Nasby@BlueTreble.com>) |
Ответы |
Re: [HACKERS] pg_get_object_address() doesn't support composites
Re: [HACKERS] pg_get_object_address() doesn't support composites |
Список | pgsql-hackers |
Jim Nasby wrote: > See below. ISTM that pg_get_object_address should support everything > pg_identify_object_as_address can output, no? > > I'm guessing the answer here is to have pg_identify_object_as_address > complain if you ask it for something that's not mapable. Yes, I think we should just reject the case in pg_identify_object_as_address. Note that you can refer to the type using it pg_type entry: alvherre=# select * from pg_identify_object_as_address(1247,'comp'::regtype, 0); type │ object_names │ object_args ──────┼───────────────┼─────────────type │ {public.comp} │ {} (1 fila) alvherre=# select * from pg_get_object_address('type', '{public.comp}', '{}');classid │ objid │ subobjid ─────────┼───────┼────────── 1247 │ 16400 │ 0 (1 fila) Trying to accept it using its pg_class entry would require adding an OBJECT_COMPOSITE_TYPE member to the ObjectType enum. I considered it back then, and eventually decided that it was not worth the trouble. Another way to think about this problem is an approach Peter E suggested not long ago, which was to change the objname/objargs representation more completely. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: