On Wed, 2008-12-10 at 16:01 -0500, Raymond Cote wrote: > Hi Everyone, > > I'm having problems loading a custom PostgreSQL trigger function during > syncdb and not sure how to address this: > The function (trimmed down) looks as follows: > > CREATE OR REPLACE FUNCTION probe_data_insert() > RETURNS SETOF trigger AS $$ > > DECLARE > ofs VARCHAR; > > BEGIN > NEW.collected_dt := NEW.received_dt; > RETURN NEW; > END; > $$ LANGUAGE 'plpgsql' VOLATILE; > > When I run that in PgAdmin2, it loads fine. > However, when I try to load it with syncdb, I get the following error: > > Installing custom SQL for data.ProbeData model > Failed to install custom SQL for data.ProbeData model: unterminated > dollar-quoted string at or near "$$ > > DECLARE > ofs VARCHAR;" > LINE 2: RETURNS SETOF trigger AS $$ > > I found one reference on the net regarding the unterminated string that > had to do with an old version of psql on the system. This is a clean OS > install and I checked that psql 8.3.4 is the only one on the system. > > Any idea what I should be doing differently?
I suspect this is because the initial SQL option isn't really ideal for custom functions like this. Rather, it's for things like populating initial data (straightforward insert statements). Django works line-by-line, each line of the file is passed in a cursor.excecute() call to the database. So the database will see "RETURNS SETOF trigger AS $$" and then in a separate statement, the next line will be passed in, which will confuse the parser of the first line, as it was expecting to processing everything up to the next "$$" occurrence. We aren't ever really going to fix this, since handling all the different special cases requires having an SQL parser in Django or lots of custom backend stuff just for this "initial SQL" feature and that's really a bit outside the scope. Yeah, okay, it should have been called "initial SQL data", but historical development's like that sometimes. The alternative approach is to listen for the post_syncdb signal to be emitted for your model and then call cursor.execute() yourself, since you know that you'll be working with PostgreSQL and what is possible. Django has to handle all sorts of cases, you just have to handle your own, so we push this back to the developers in this case. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
