Dynamic variable parsing interferes with SQL function definition syntax

[Dave Abrahams <dave@…>]

I don't know if this is a PostGreSQL-specific issue or not, but in:

CREATE OR REPLACE FUNCTION xticket1(query_param TEXT)
   RETURNS SETOF tix
   AS
$foo$
  ...
$foo$

Trac incorrectly attempts to perform a dynamic variable substitution on $foo, which naturally fails.

The workaround I have, which seems to work, is to use $$ instead of $foo$. I'm too SQL-illiterate to know whether that's a serious limitation or not.

[Noah Kantrowitz]

Generally you wouldn't be making a stored procedure in the report itself, you would just be using it.

[Dave Abrahams <dave@…>]

Replying to nkantrowitz:

Generally you wouldn't be making a stored procedure in the report itself, you would just be using it.

Yes, it's not the most common use case, but I needed it. You might consider checking for $<identifier>$<not-an-identifier> and avoiding expansion, though.

[sid]

Having stored procedures within a report really seems to be an edge case. Propose closing this as wontfix.

[Christian Boos]

… and apparently there's a workaround as you said (using $$), so that seems good enough.