Hi Adrian: On Sun, Apr 6, 2014 at 5:05 PM, Adrian Klaver <adrian.klaver@xxxxxxxxxxx> wrote: > On 04/06/2014 05:30 AM, Francisco Olarte wrote: >> I think a trigger is overkill for just a simple data-combining >> procedure. JMO, but I prefere to reserve triggers for htings which >> need them. > Well the flip side to that argument is that a trigger is a single point of > reference for the data changing. You can hit the table from wherever and > whatever and have the same thing happen. No wrestling with ORMs to get > database specific code to run. No tracking down where the query is that is > munging the data. Not saying one approach is inherently better than the > other, just that there are options. You raise some notable points. Specially in the ORM wrestling part, which I never thought of as I hate them. I'm still partial to some normal logic, perhaps hidden in a procedure which may be invoked on an instead trigger on inserts of a dedicated view ( data changing insert triggers scare me, I like to be able to select what I've just inserted, so I would prefer to insert into a view with only the ids and extra part and recover the full files from another table / view ). Although I still think that given his original statement the best would be to select some values from the sequence, rename the files and insert them after, or what I did for something similar once, insert the rows with the original names and then rename the files after insert, and, after a crash, find leftover unrenamed files, rescan table for them and rename. Francisco Olarte. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
