Re: Inconsistent compilation error - Mailing list pgsql-general

On 04/18/2018 06:02 PM, raf@raf.org wrote:
> Hi,
> 

> 
> But I'm getting this compilation error when it tries to load this
> function:
> 
>      ERROR:  too many parameters specified for RAISE
>      CONTEXT:  compilation of PL/pgSQL function "tla_audit_delete_thing" near line 9
> 
>      Traceback (most recent call last):
>        File "lib/loadfunc.py", line 228, in main
>          db.cursor().execute(src)
>        File "/usr/lib/python2.7/dist-packages/pgdb.py", line 1026, in execute
>          return self.executemany(operation, [parameters])
>        File "/usr/lib/python2.7/dist-packages/pgdb.py", line 1050, in executemany
>          rows = self._src.execute(sql)
>      ProgrammingError: ERROR:  too many parameters specified for RAISE
>      CONTEXT:  compilation of PL/pgSQL function "tla_audit_delete_thing" near line 9
> 
> The line in question is:
> 
>      raise notice '% %', 'blah_history.original_id', r;
> 
> Which looks fine. The really wierd thing is that this happens when done on a
> debian9 host but when I load the function from another host (my macos laptop)
> with the same function into the same database, it works fine.
> 
> I've never encountered an inconsistency like this before.
> 
> Any suggestions as to what might be causing it?
> 
> The python versions are slightly different and the pgdb module versions
> are different but I wouldn't have thought that that would affect the
> compilation performed by the database server itself:
> 
>    debian9:       python-2.7.13 pgdb-5.0.3

Hmm, wonder if there is an oops in the below:

http://www.pygresql.org/contents/changelog.html

Version 5.0 (2016-03-20)
Changes in the DB-API 2 module (pgdb):
"SQL commands are always handled as if they include parameters, i.e. 
literal percent signs must always be doubled. This consistent behavior 
is necessary for using pgdb with wrappers like SQLAlchemy."


>    macos-10.11.6: python-2.7.14 pgdb-4.2.2
> 
> And the sql sent to the database server is identical from both hosts.
> 
> And I don't think anything much has changed on the debian host recently.
> 
> And it's not just the old backup. The same is happening with other copies of
> essentially the same database.
> 
> And all the other stored functions were loaded fine. It's just this one that
> went wrong.
> 
> Thanks in advance for any insights you can share.
> 
> cheers,
> raf
> 
> 
> 


-- 
Adrian Klaver
adrian.klaver@aklaver.com