I am facing a problem regarding global temporary tables in Postgres Sql. If two procedures:
A() having a temporary table say temp(id, name)
B() having a temporary table say temp(id, name, address)
then if the procedure A is called first and after that procedure B is called then the temp table remains with the structure i.e. temp(id, name) defined in the procedure A and vice versa and the column "address" as defined in procedure B is not found.
Please help me to find a solution???
If you really need to have explicit temporary tables, just create these with a unique name.
Anyway, the common approaches would be to handle it in SQL selects without explicit temporary tables, possibly extended by using with queries (common table expressions).
Basically you have two options.
The first is to make your tables unique so that they don't hit the same ones. This would be preferred if you are using these to store longer-term session-specific data. These could be named uniquely.
A second is that you can create, use, and drop your tables inside the same stored procedure so that stored procedure A can be generally guaranteed that relation temp does not exist when starting and the same with stored procedure B.
Related
I have DB- A and B. Both the DBs have a table called 'company'.
I want to check whether both the tables are identical with their data or not.
You could export the data from both tables (with the same ORDER BY clause) and compare the resulting files, or you could define a postgres_fdw foreign table that presents one table in the other database, then use EXCEPT to compute differences.
Suppose a temp table would be created and dropped during a stored procedure. What if multiple users run the stored procedure at the same time, does it cause any problem like unable to create that temp table because it's been already created by another user and hasn't been dropped yet in time before someone tries to create that temp table?
As long as you're talking about an actual #temp table (with a single #) there are no problems. A #temp table is scoped to the session. So you can have dozens of people on the same instance, all creating temp tables with the exact same name, at the exact same time and you'll never have a collision. (It's a different story if you're talking about ##globaltemp tables (with 2 ##)... Global temps can and do collide with other sessions)
I want to rename a column in a table. I see two approaches
Use sp_rename() and modify stored procedures to refer to new name.
Create new column, copy data from old column to new column, modify stored procedure etc. to refer to new column, eventually drop old column.
We can't use #1 as renaming column might leave stored procedures broken and we cannot afford any downtime.
If we go with #2, there is possibility that both old and new columns would co-exist for sometime after the data is copied over from old to new column but before the stored procedures deployed to use the new column.
Is there any way to keep the new column in sync with any updates/insert/deletes done to old column?
Can the AFTER triggers help here? But triggers usually increase the transaction time, so may not be a favorable solution.
Can I replicate data between two columns of the same table?
Any other possible solutions?
Also does sp_rename() cleanly updates all the references to the column - like stored procedures, functions, indexes etc?
First confirm there are no references to the column from outside the database like application code directly querying the column without going through stored procedures.
Here is how I renamed the column without causing the downtime -
Add a new column besides the existing column. The new column has same data type as the old column but the new name.Also create indexes, modify replication etc. on the new column based on the use cases.
Modify all stored procedures writing (insert/update operations) to the old column to also insert/update in the new column.
Copy over the data from old column to the new column for the existing records. Step 2 and 3, together, now ensure that the new column will remain in sync with the old column.
Modify all stored procedures reading from the old column to now read from the new column.
Now that all code has transitioned to use new column, we need to clean up -
Modify stored procedures from earlier Step#2 to stop referring to old column.
Drop the old column.
You could rename your table and create a view using the old table name and have the view include an alias for your column.
SQLPrompt by redgate has a feature called Smart Rename which can rename a column and update all of the references to the new name.
From SQL Prompt 7 documentation:
SQL Prompt can create a script that allows you to rename objects in your database without breaking dependencies. You can rename the following:
Tables (including columns)
Views (including columns)
Stored procedures (including parameters)
Functions (including parameters)
When an object is renamed:
SQL Prompt also modifies any objects that reference, or are referenced by, the renamed object to ensure that dependency links are not broken.
If you have previously renamed an object using SQL Server Management Studio or Enterprise Manager Rename, or the T-SQL sp_rename command, the object definition will contain the original name.
Any objects that reference this original name are not updated.
To help you locate objects that reference objects that no longer exist, see Finding invalid objects.
The original permissions and extended properties of the object are preserved.
I'm making changes to a Sql Server (2008) database to change an existing column type from a UUID to a varchar(128) - the column, we'll call it reference was originally used to save an ID of a reference project that provided more information about the data in the row, but now the business requirements have changed and we're just going to allow free-form text instead. There were no foreign keys setup against the column, so there won't be any breaking relationships.
My biggest concern at the moment is one of backwards compatibility with existing stored procedures. Unfortunately, the database is very big and very old, and contains hundreds of stored procs littered throughout the design. I'm very nervous about making a change which could potentially break existing stored procs.
I know this is a loaded question, but in general, can UUID columns be converted into varchar columns without deleterious effects? It seems like any existing stored proc which inserted into or queried on the UUID column would still work, given that UUIDs can be represented as strings.
I've tried performed the below steps and I didn't see any issues, so i think you can go ahead and change the column datatype:
Created the table with the column type as unique identifier.
Created the stored procedure to insert a value into that table through NewID() function.
Execute the stored procedure, and data was inserted without any issue.
Now, I changed the column type to varchar and again executed the stored procedure.
Procedure ran fine without any issue, and data was inserted.
So, the answer is Yes, you can change the column data type.
In my Application, I need to create few temporary tables. Do I need to execute the SQL in each session to create temp tables else can I run the SQL manually once, and can use those temporary tables in each session?
From the fine manual:
Temporary Tables
Although the syntax of CREATE TEMPORARY TABLE resembles that of the SQL standard, the effect is not the same. In the standard, temporary tables are defined just once and automatically exist (starting with empty contents) in every session that needs them. PostgreSQL instead requires each session to issue its own CREATE TEMPORARY TABLE command for each temporary table to be used. This allows different sessions to use the same temporary table name for different purposes, whereas the standard's approach constrains all instances of a given temporary table name to have the same table structure.
So temporary tables are local to each session and each session will need its own CREATE TEMPORARY TABLE and the temporary tables will be different in each session even if they have the same name.