I get the error "Incorrect syntax near the keyword 'truncate'." and not sure what's wrong with the syntax here, it's not obvious to me...probably something stupid but I need another set of eyes:
ALTER VIEW [dbo].[vw_All_Events]
AS
truncate table Event
Select [event_id]
,[site_id]
,[autogenerated]
,[creation_date]
,[last_update_date]
from Event
GO
A view only allows a single statement after the AS and it must be data retrieval (return a rowset). It can't be a different type including data definition, data modification, procedural, declarative, or any other.
You can do these things with a stored procedure, or a user-defined function (but can't do DDL & DML in a function).
In detail, a stored procedure allows flow-of-control statements like IF THEN ELSE BEGIN END WHILE RETURN. You can use DML to UPDATE, DELETE and INSERT. You can use DDL to CREATE and DROP tables and indexes, add columns and constraints, and so on. You can return multiple rowsets. You can execute dynamic SQL.
What are you trying to accomplish?
Better way, you use a stored procedure instead of view.
There are you write multiple statement and also get output.
You can only have select statements in views. Therefore, 'truncate' is an invalid command to use.
TRUNCATE does not work with views.
Check out this link
Related
I'm trying to analyze if the triggers before and after on my table with huge data to check for any bottlenecks and for improvements but i'm getting syntax error and wanted to see if it's possible to do EXPLAIN ANALYZE COPY
i did some research but couldn't find if it's possible or not
As documented in the manual the following statements can be explained
Any SELECT, INSERT, UPDATE, DELETE, VALUES, EXECUTE, DECLARE, CREATE TABLE AS, or CREATE MATERIALIZED VIEW AS statement, whose execution plan you wish to see.
The COPY command is not in that list
I would like to keep some computed columns in several tables and columns (PostgreSQL). The calculation is the same but there might be practically any number of tables and columns. So if the input is table1.field1 then the calculated field is table1.field1_calculated . And so forth. I was thinking on using triggers to maintain this, one trigger per field. This would require passing in the table and the field name as arguments into the function, assembling a SQL statement and executing it. I do not want to rely on plpgsql as that might not be available everywhere and everything I can find about dynamic SQL in PostgreSQL is a) old b) says you need plpgsql for that.
So
Is there a way in PostgreSQL 9.4+ or perhaps 9.5+ to create and execute dynamic SQL without plpgsql?
Is there a better way than triggering this function containing said dynamic SQL?
Ps. I am aware of the function/column notation trick but that doesn't really work here. For 2. I am suspecting rules might work but can't figure out how.
I am writing trigger for record updation in Postgresql using plpgsql . In trigger, I am accessing one value column value like below
NEW.mobileno -- This is usual way.
Now my requirement is , I will be having 'mobileno' text in one variable called dyn_columnname
Using this NEW and dyn_columnname , I should be access like NEW.mobileno value.
How can I achieve this..?
You need to use dynamic sql:
execute _dyn_sql_string into _dyn_col_value using _dyn_col_name;
http://www.postgresql.org/docs/current/static/plpgsql-statements.html#PLPGSQL-STATEMENTS-EXECUTING-DYN
It's usually better to avoid ending up with this situation to begin with, that being said, because the resulting query plans cannot be cached as efficiently as the plans from non-dynamic triggers.
If you're simply iterating through columns, consider approaching this by using dynamic sql, not to write a dynamic trigger function, but to write a dynamic function that creates or replaces a non-dynamic trigger function instead.
If you're using this because of some kind of business logic, consider revisitng your schema to aboid the situation entirely.
I'm trying to create a trigger on my table such that it only runs if the 'prepaid' column is true for rows where I've modified the value of the 'points_per_month' column. I tried this:
CREATE TRIGGER "fix_usage_trigger"
AFTER UPDATE OF "points_per_month"
ON "public"."clients"
FOR EACH ROW WHEN (ROW.prepaid)
EXECUTE PROCEDURE "fix_prepaid_client_available_usage"();
psql is telling me this:
ERROR: missing FROM-clause entry for table "row"
LINE 1: ...r_month" ON "public"."clients" FOR EACH ROW WHEN (ROW.prepai...
Clearly I have no FROM clause there, but I'm not sure why I'd need one, nor where to put it.
That should be when (new.prepaid), per David's comment. You can access old and new in the when clause (as in the row before and after the update) much like table aliases. The error message is PG complaining that row is not a known table.
Two additional notes:
it might need to be when (old.prepaid or new.prepaid) if you want to manage billing plan switches -- or another two separate triggers. Conversely, when (old.prepaid and new.prepaid) if you do not, and someone might run database queries that might inadvertently fire the trigger and create undesirable state (add a unit test or two).
the function's name suggest something might be wrong further up in your code flow. You might want to fix that instead, by setting the available usage properly to begin with. Doing so might be more efficient, too.
Let's suppose I have a trigger function, but its code is so complex that it would be handy to split it to more procedures. I want to operate with the NEW (or OLD for UPDATE/DELETE triggers) variable in all of them. Is there any alternative to sending it as a function parameter to every procedure called from the original trigger function?
If you really need to pass them around, I'm quite sure you can do so as appropriately typed records (e.g. newrow tablename%ROWTYPE).
http://www.postgresql.org/docs/current/static/plpgsql-declarations.html
That said, unless you run giant queries whose results you use throughout the trigger function, breaking the trigger into smaller parts is usually a cleaner than calling subfunctions imho. Note that you can conditionally execute the triggers, e.g.:
create trigger "01_do_stuff_upd" on update after tablename
for each row
when (old.field <> new.field and ...)
execute procedure do_stuff_upd_part_01();
The thing to have in mind when doing the above, is that in Postgres (and contrary to the sql spec), the triggers are executed in alphabetical order rather than in the order they're created.