Export layer to PostgreSQL directly from layer export dialog

[tjukanovt]

Feature description.

Currently when exporting a vector layer to PostgreSQL/PostGIS, there are (at least) optional ways to achieve this: via DB Manager or Processing Toolbox (export to PostgreSQL).

However I would think that the most logical way to do this would be through the Layer panel and the dialog that opens up when you click Export Layer --> Save Feature As --> _The Save Vector Layer as... dialog has an option to save the data as an SQL dump, but not directly to a database.

Would be very nice if that path (right clicking the layer) would open up similar dialog as the Export to PostgreSQL tool.

[elpaso]

@tjukanovt the most straightforward way is probably drag and drop from the QGIS browser panel.

[tjukanovt]

@elpaso True. That's a third way to do the same thing. However that way of importing is very simple and for example just fails in case there is already a layer in the schema with the same name. I think having the export option inside the Save Features As dialog would be logical.

[elpaso]

@tjukanovt I'm not against this request, but honestly I'm not sure about cluttering the context menu: should we expose the export options to other providers as well?

[tjukanovt]

@elpaso Valid point.

I would maybe prefer to have three different options when right-clicking the layer: export layer style, export layer to file and export layer to database. Not 100% sure what is the best option from UI/UX point of view though.

[tjukanovt]

Just recently realized that there is also a method to do this through the GDAL tools in QGIS and that seems to provide you with the most options (e.g. _append to existing table i_s missing from the "normal" Export to PostgreSQL)

So I saw that you @elpaso had an enhancment proposal on doing something like this. I would be happy to help/test and share my experiences if you start doing something in this area.

Now I feel like there are way too many ways to do the same thing.

[elpaso]

So I saw that you @elpaso had an enhancment proposal on doing something like this. I would be happy to help/test and share my experiences if you start doing something in this area.

That proposal is not related in any way to export data. It's about changing the schema and adding new tables.

[gioman]

Just recently realized that there is also a method to do this through the GDAL tools in QGIS and that seems to provide you with the most options (e.g. _append to existing table i_s missing from the "normal" Export to PostgreSQL)

@tjukanovt it is also much faster than any other tool (to import data in PostGIS) available in QGIS.

[tjukanovt]

@gioman Yes noticed that too!

Sorry @elpaso I think I read it too quickly.

I think this part of QGIS is one of those that would definitely need some streamlining. Now there are too many tools to achieve same goals with different user experiences and different performance.

[elpaso]

@tjukanovt I agree that we probably should consolidate the tools, but some code paths are really meant to be generic and work out of the box without user intervention (like drag & drop in the browser) other are more suitable for advanced fine-tuned operations.

I'm not sure we can merge them all in a single tool.

[tjukanovt]

@elpaso Absolutely. I don't think a single tool can achieve all functionalities, but now just in the Processing toolbox there are two different methods:

IMHO DB Manager is the one that doesn't really have a clear role among the tools and also according to my experience it is the most unreliable (and slowest) of these. Also DB Manager seems to be breaking with almost every new release in one way or another according to my experience.

[elpaso]

IMHO DB Manager is the one that doesn't really have a clear role among the tools and also according to my experience it is the most unreliable (and slowest) of these. Also DB Manager seems to be breaking with almost every new release in one way or another according to my experience.

Yeah, we are trying hard to bury it and replace it with C++ core implementations, and that's what my grant proposal is about (another small step towards DB manager funeral).