On Tue, Apr 17, 2018 at 06:28:19PM +0200, Pavel Stehule wrote: > I though about it, and I am inclined to prefer pg_class instead separate > tables. > > It true, so there are lot of "unused" attributes for this purpose, but > there is lot of shared attributes, and lot of shared code. Semantically, I > see variables in family of sequences, tables, indexes, views. Now, it > shares code, and I hope in next steps more code can be shared - > constraints, triggers. > > There are two objective arguments for using pg_class: > > 1. unique name in schema - it reduces risk of collisions > 2. sharing lot of code > > So in this case I don't see well benefits of separate table.
Understood. I haven't strong opinion here though. But I thought that pg_class approach may limit extensibility of variables. BTW: - there is unitialized variable 'j' in pg_dump.c:15422 - in tab-complete.c:1268 initialization needs extra NULL before &Query_for_list_of_variables Also I think makeRangeVarForTargetOfSchemaVariable() has non friendly argument names 'field1', 'field2', 'field2'. -- Arthur Zakirov Postgres Professional: http://www.postgrespro.com Russian Postgres Company