Csdrhrt

It's impressive how many different vector file formats QGIS (using ver 3.6.0) allows me to save a layer as:

But as far as I can tell, QGIS doesn't allow me to save a vector layer to memory. In my normal workflow in manipulating vector layers, I find myself having to save several intermediate vector layers to file, clogging up my file system or databsase with something like "vector_layer", "vector_layer1", "vector_layer2", "vector_layer2a", etc. It is often trivial to perform the updates/edits to the layer, and because I really don't care about these intermediate files, I'd rather be able to just save them in memory within the QGIS environment. Saving to memory would allow me to simply remove the layers from the project when I finish my workflow instead of having to delete from my Postgres database or my desktop.

When performing a geoprocessing task, there is the option to save to memory, but why can't I have the option to export a layer to memory on its own?

Try outputting a specific format to memory using the special "/vsimem" virtual filesystem.

For example:

As a workaround, you can copy a layer to memory by running a processing tool in a way that generates an identical layer, and output the tool to [Create temporary layer].

For example, use the default $geometry expression in the Geometry by expression tool:

Other options include:

• for polygon layers, Buffer tool with buffer distance of 0


• Translate tool with all offset distances 0


• Reproject Layer tool with Target CRS the same as the layer's current CRS

etc.

Less an answer, but mere suggestions in the more flexible direction of SQL, as I personally think that the need for what you describe might be a hint to change your workflow (no offense), at least within the QGIS/PostGIS environment...

• 
  use the SQL GUI:
  
  since you explained a common task is manipulating the attributes (without necessarily saving the results), work with the DB Manager. Next to a full scale PostgreSQL/SpatiaLite client, the DB Manager provides the full SpatiaLite SQL interface for all project layers.
  
  Run queries to aggregate or analyze the attributes, stack queries to work with intermediate results, view them live in the GUI and load them as (memory) layers for further geoprocessing if needed (this works with simply copying the base layer, too).
  
  
  


• 
  use Virtual Layers:
  
  similar to the features and handling from above, the Virtual Layers are flexible and multi-source instances of memory layers that are defined and manipulated with SQL.
  
  
  Add a Virtual Layer, define it's sources and manipulate its data as needed, with the power of SQL just as above. Use it in further geoprocessing, save it's definition to .qlr and reuse it in other projects.
  
  
  


• 
  use Views:
  
  on DB level, simply save your queries as Views and load them into QGIS.
  
  Again, as above, you can view (no kidding) the results of queries just as with other layers, and use its 'data' in further geoprocessing, save to file or whatever. You can't and/or shouldn't edit in QGIS itself, though, without a bit of a setup in the DB.

The Virtual Layers can actually combine all these; you can add literally any data source supported in QGIS to its sources, and switch sources as needed. All these options effectively save to memory, with a name of your choice...

I work with this stack a lot, and I honestly can't remember the last time I used the export.