Skip site navigation (1) Skip section navigation (2)

Re: pg_execute_from_file review

From: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
To: Joshua Tolley <eggyknap(at)gmail(dot)com>
Cc: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_execute_from_file review
Date: 2010-11-26 11:30:37
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Joshua Tolley <eggyknap(at)gmail(dot)com> writes:
>> > * I'd like to see the docs slightly expanded, specifically to describe
>> >   parameter replacement. I wondered for a while if I needed to set of
>> >   parameters in any specific way, before reading the code and realizing they
>> >   can be whatever I want.
>> My guess is that you knew that in the CREATE EXTENSION context, it has
>> been proposed to use the notation @extschema@ as a placeholder, and
>> you've then been confused. I've refrained from imposing any style with
>> respect to what the placeholder would look like in the mecanism-patch.
>> Do we still want to detail in the docs that there's nothing expected
>> about the placeholder syntax of format?
> Perhaps such docs will show up with the rest of the EXTENSION work, but I'd
> like a brief mention somewhere.

I'm unclear about how to spell out what you'd like to be seen in there,
so I'm not proposing a newer version of the patch.

>> > * Shouldn't it include SPI_push() and SPI_pop()?
> My guess is "yes", because that was widely hailed as a good idea when I did
> PL/LOLCODE. I suspect it would only matter if someone were using
> pg_execute_from_file within some other function, which isn't entirely
> unlikely.

In fact, per the fine manual, it seems unnecessary doing so when using
SPI_execute(), which is the case here:

  Note that SPI_execute and related functions automatically do the
  equivalent of SPI_push before passing control back to the SQL
  execution engine, so it is not necessary for you to worry about this
  when using those functions.

For information, we've been talking about the case on IRC and Joshua and
we are agreeing on this conclusion.

Dimitri Fontaine     PostgreSQL : Expertise, Formation et Support

In response to

pgsql-hackers by date

Next:From: Radosław SmoguraDate: 2010-11-26 12:05:30
Subject: Re: Workarounds for getBinaryStream returning ByteArrayInputStream on bytea
Previous:From: Pavel StehuleDate: 2010-11-26 10:42:26
Subject: Re: memory leak in libxml2 - fix

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group