I am using a tool called giswater to model our water sewer and storm networks. The tools builds a database from a few simple inputs in a gui one of which is the SRID. the geometry columns are all xy and I want to make them all ZM aware. When I run the alter table command to update the geometry I get an error "Cannot alter column participating in a view or rule"
Anyway to force this change and ignore the error? I tried changing the view to not reference the column and I tried adding a new geometry column to switch the view to temporarily while I make the change. Apparently I cannot drop a column in a view or change it to another column. I also tried writing the schema to SQL then edited the sql lines for linestring and point to linestringzm and pointzm and using psql to run the file to update the schema; all I get is access denied using "psql -U postgres -d utility -1 -f \i Z:......\xyz_test.sql"
Also tried pg_restore.
Anyway to just force the change using pg_admin4? or other suggestions?
I am not familiar with the tool you are using but I would suggest checking all the objects (views and rules) referencing your table by using the below command.
SELECT DISTINCT so.name
FROM syscomments sc
INNER JOIN sysobjects so ON sc.id=so.id
WHERE sc.TEXT LIKE '%tablename%'
Then backing up these object and dropping them completely before attempting to alter the table.
Related
Is there a way to drop all the data types listed by \dT+.
I know you can drop types individually via DROP TYPE command, but I have a lot of types and it's painstaking to drop them all individually.
Following the directions suggested by user Schwern, I used psql -E and got this to work:
Run SELECT typname, typnamespace from pg_type;
Figure out what typnamespace your types are associated with
DELETE FROM pg_type WHERE typnamespace=${your_typnamespace}
pg_dump --table=export_view --data-only --column-inserts mydb > export_view.sql
pg_dump (PostgreSQL) 10.7 (Ubuntu 10.7-1.pgdg18.04+1)
Export specific rows from a PostgreSQL table as INSERT SQL script and the postgresql documentation (https://www.postgresql.org/docs/10/app-pgdump.html) suggest it is possible to pg_dump from a view with the --table flag. If I export from the table directly I get the expected result (ie, data is exported). If I select from the view in psql I get the expected result. However whether I create a view or a materialized view and then try and pg_dump, I get only the normal pg_dump headers and no data. A commenter (https://stackoverflow.com/users/2036135/poshest) also appears to have faced the same issue in the above SO question, with no solution given.
If I CREATE TABLE blah AS SELECT x, y, z FROM MYTABLE then I can export fine. If I CREATE VIEW blah AS SELECT x, y, z FROM MYTABLE then the export is empty.
What am I doing wrong?
As #bugmenot points out, version 13 (and above?) - the current at the time this answer is written - indeed has clarification on what gets dumped:
As well as tables, this option can be used to dump the definition
of matching views, materialized views, foreign tables, and sequences.
It will not dump the contents of views or materialized views, and the contents of foreign tables will only be dumped if the
corresponding foreign server is specified with --include-foreign-data.
(emphasis added).
So the answer (to myself) is: "You are not doing anything wrong, except that you incorrectly interpreted the documentation for Postgres <=12. What you want to do is not possible."
Views do not store data, they provide a dynamic view onto it. When you include views in your dump, you will only get the view definition.
I found some random RULES in some database views that returns a SELECT which is exactly the view's select.
I did search through migrations and application code but found no definition/creation of those rules.
Does Postgres 8.4 creates RULE automatically on some views?
It is essentially the same to create a view or create a table and create a rule on SELECT. It is valid not only for 8.4, but till 9.6 inculsive:
...an ON SELECT rule effectively turns the table into a view
and further:
It is considered better style to write a CREATE VIEW command than to
create a real table and define an ON SELECT rule for it.
I have two databases on the same server and need to copy data from a table in the first db to a table in the second. A few caveats:
Both tables already exist (ie: I must not drop the 'copy-to' table first. I need to just add the data to the existing table)
The column names differ. So I need to specify exactly which columns to copy, and what their names are in the new table
After some digging I have only been able to find this:
pg_dump -t tablename dbname | psql otherdbname
But the above command doesn't take into account the two caveats I listed.
For a table t, with columns a and b in the source database, and x and y in the target:
psql -d sourcedb -c "copy t(a,b) to stdout" | psql -d targetdb -c "copy t(x,y) from stdin"
I'd use an ETL tool for this. There are free tools available, they can help you change column names and they are widely used and tested. Most tools allow external schedulers like the windows task scheduler or cron to run transformations based on whatever time schedule you need.
I personally have used Pentaho PDI for similar tasks in the past and it has always worked well for me. For your requirement I'd create a single transformation that first loads the table data from the source database, modify the column names in a "Select Values"-step and then insert the values into the target table using the "truncate" option to remove the existing rows from the target table. If your table is too big to be re-filled each time, you'd need to figure out a delta load procedure.
Within PHP I do:
1.) A temporary table is created: CREATE TEMP TABLE new_table AS SELECT .... FROM ...;
2.) AFter that I want to use this table to create a shape file: shell_exec ("pgsql2shp .... -u username -P password ...);
Separetly those two things work, but by creating a temporary table and after that using this table in pgsql2shp does not work. I pressume this is because temporary table duration is to the end of session. But to create shp file I need to use username and password what means new session starts and temporary table is dropped before I use it for shape creation.
Any tip how to solve it?
Thank you!
Yes, temporary tables are dropped at the end of the session or optionally at the end of the transaction. In general you cannot pass them to another process.
Create a real table, give it a unique name by sticking an id to it and drop the table after running the shape creation.
If you cannot change the pgsql2shp program, you might wrap it in a script and call that instead. However you should be able to pass the name of the table to the pgsql2shp program.
Can't you run the query in the pgsql2shp program?
As an alternative, the humble flatfile in the /tmp folder can also work very well.