Open rkhaotix opened 2 years ago
This would be great!
Extensions in pgModeler now support the handling of multiple data types. For other object types like operators, functions, etc. There are plans to include them but it'll require a more elaborate change in the core library which can take some time.
A work around for this: create a database in your pg server, add the extensions you want to be able to model with, import the database into pgmodeler and save the .dbm as something like extension-template. Any time you want to create a model that will use features from those extensions, you can load this .dbm and then save it under the name of your model.
Seems easier, to me, than manually creating the features you need.
@seven0f That's an good alternative. Anyway, I have some solutions in mind to cover this issue completely allowing one to create quickly any object type tied to an extension.
Your workaround sounds good but it would include objects that can be never used in a database model. For example, say you want to use an extension days type but don't need any other object that the extension creates (operators, functions, operator classes, etc) this could bloat your model.
I completely understand, just a suggestion.
What would be really cool, and I have no idea if this is feasible, is a system that can read in an extension so the user (me!) can select the features I need to add to my project. Perhaps another pro feature.
@seven0f That is what I'm planning to do. Create some kind of template objects storage that can be reused in any data model. :)
Currently, using a PostgreSQL extension can be a bit confusing, mainly when the extension installs two or more data types, which demands the creation of dummy data types so they can be available for modeling purposes.
It would be great if in the extension dialog we could specify the objects that are installed with the extension (data types, functions, and other objects). In the extension dialog, the user must be able to create dummy objects to make them available in the model. These objects must be somehow tied to the parent extension and be destroyed automatically when the extension is too, not allowing the user to edit or delete them separately.