I am using Postgres 10.3.
Based on this question, I use:
ALTER TYPE name RENAME VALUE attribute_name TO new_attribute_name
to rename an enum value.
But I need a solution that works with Postgres 9.6 that does not require updating pg_enum manually because it needs permissions that I don't have.
There is no supported way to rename an enum value in PostgreSQL 9.6.
Directly modifying pg_enum is something you should not only rule out because of permission issues, but also because directly messing with the system catalogs is dangerous and may destroy your data.
You should use enums with care. They are only good if they never need to be modified. If there is a chance that the enum values won't be immutable, use a lookup table instead.
Related
I am new to databases and I was trying to set up PostreSQL and trying to query
tables in pgAdmin 4, but I always have to specify schema name as such:
SELECT * FROM infection_database.country
The database name is the same as the schema name. This is probably not good but I didn't know better.
I tried looking up some solutions and found and tried this, but it didn't fix the issue:
ALTER DATABASE infection_database SET search_path="infection_database";
Tried both with and without quotation marks if it matters. Where am I making a mistake?
Given solution works, but you need to restart the session for the changes to take effect.
Credit to #jjanes
I am migrating this Oracle command to PostgreSQL:
CREATE SYNONYM &user..emp FOR &schema..emp;
Please suggest to me how I can migrate the above command.
PostgreSQL does not support SYNOSYM or ALIAS. Synonym is a non SQL 2003 feature implemented by Microsoft SQL 2005 (I think). While it does provide an interesting abstraction, but due to lack of relational integrity, it can be considered a risk.
That is, you can create a synonym, advertise it to you programmers, the code is written around it, including stored procedures, then one day the backend of this synonym (or link or pointer) is changed/deleted/etc leading to a run time error. I don't even think a prepare would catch that.
It is the same trap as the symbolic links in unix and null pointers in C/C++.
But rather create a DB view and it is already updateable as long as it contains one table select only.
CREATE VIEW schema_name.synonym_name AS SELECT * FROM schema_name.table_name;
You don't need synonyms.
There are two approaches:
using the schema search path:
ALTER DATABASE xyz SET search_path = schema1, schema2, ...;
Put the schema that holds the table on the search_path of the database (or user), then it can be used without schema qualification.
using a view:
CREATE VIEW dest_schema.tab AS SELECT * FROM source_schema.tab;
The first approach is good if you have a lot of synonyms for objects in the same schema.
Setup:
liquibase 3.3.5
PostgreSQL 9.3
Windows 7 Ultimate
Having set the Liquibase.properties file with
changeLogFile = C://temp/changeset.xml,
I created a diff file with Liquibase (3.3.5).
liquibase.bat diffChangeLog
Examination of the changeset.xml file shows
-<addColumn tableName="view_dx">
<column type="int8" name="counter" defaultValueNumeric="0" defaultValue="0"/>
</addColumn
Problem is when
liquibase.bat update
is run, the changed table is NOT in the same column order as the reference table. This causes issues with the stored procedures using SETOF to return table rows.
Without destroying the existing table on the target database, how can column order be enforced using Liquibase?
TIA
I don't think that you can, in general, get Liquibase to enforce a column ordering. You will probably need to change your stored procedures to use column names rather than relying on position, which is a good habit to get into anyway.
Have you tried using afterColumn attribute of addColumn tag ?
I have a Postgres 9.3 database which, by mistake, has been set to:
but I need it to be:
Since the Encoding doesn't change, it is safe to dump the DB and restore it later (see here) to a database with the new Collation / Character type?
Perfectly safe -- the collation is just telling Postgres which set of rules to apply when sorting text.
You can even set it dynamically on a query basis in the order by clause, and should be able to alter it without needing to dump the database.
I'm new to Postgres OIDs.
I want to know, wre the SQL, Postgres OIDs are dynamic or static?
Means after creating OIDs is there any possibility to change them automatically or manually?
PostgreSQL OID is static, but it will not survive dumping and restoring the database, so you should NOT rely on it.
Actually, in PostgreSQL 8.1 and later, configuration parameter default_with_oids is false by default, which means that unless you use CREATE TABLE using WITH OIDS option, OIDs will NOT be present in your table.
So, long story short - OIDs are thing of the past. Do not use it, do not rely on it, forget about it.