pgmodeler / pgmodeler

Open-source data modeling tool designed for PostgreSQL. No more typing DDL commands. Let pgModeler do the work for you!
https://pgmodeler.io
GNU General Public License v3.0
3.13k stars 397 forks source link

Improve PostgreSQL extensions usage #1630

Open rkhaotix opened 2 years ago

rkhaotix commented 2 years ago

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.

benjamin-kirkbride commented 2 years ago

This would be great!

rkhaotix commented 1 year ago

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.

ghost commented 5 months ago

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.

rkhaotix commented 5 months ago

@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.

ghost commented 5 months ago

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.

rkhaotix commented 5 months ago

@seven0f That is what I'm planning to do. Create some kind of template objects storage that can be reused in any data model. :)