From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Craig Ringer
There's no formal extension API. So there's no boundary between "internal stuff
we might have to change to fix a problem" and "things extensions can rely on
not changing under them". In
On 1 July 2016 at 08:33, Tsunakawa, Takayuki wrote:
> Hello,
>
> While I was thinking of application binary compatibility between
> PostgreSQL releases, some questions arose about C language user-defined
> functions (UDFs) and extensions that depend on them.
>
> [Q1]
> Can the same UDF binary be
> From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier
> So perhaps the best answer, is not 1 nor 2. Just saying that the routines
> are carefully maintained with a best effort, though sometimes you may need
> to rebuild depending on un
On Fri, Jul 1, 2016 at 12:19 PM, Tsunakawa, Takayuki
wrote:
>> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
>> To make this situation better, what we'd really need is a bunch of work
>> to identify and document the specific APIs that we would promise won't change
>> within a release branch. That id
> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> "Tsunakawa, Takayuki" writes:
> > Option 2:
> > Rebuild UDFs with the target PostgreSQL distribution.
> > You do not have to rebuild UDFs when you upgrade or downgrade the
> > minor release. (If your UDF doesn't work after changing the minor
> > rele
On Fri, Jul 1, 2016 at 11:33 AM, Tsunakawa, Takayuki
wrote:
> OK, I understood that your choice is option 2. And the UDF developer should
> report the problem and ask for its reason on pgsql-bugs, possibly end up
> haveing to rebuild the UDF. But if so, it sounds like option 1. That is,
> "F
> From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier
> On Fri, Jul 1, 2016 at 10:35 AM, Tsunakawa, Takayuki
> wrote:
> > I'd like to document the policy clearly in the upgrade section of
> PostgreSQL manual, eliminating any ambiguity
"Tsunakawa, Takayuki" writes:
> I'd like to document the policy clearly in the upgrade section of PostgreSQL
> manual, eliminating any ambiguity, so that users can determine what they
> should do without fear like "may or may not work". Which of the following
> policies should I base on?
> Op
On Fri, Jul 1, 2016 at 10:35 AM, Tsunakawa, Takayuki
wrote:
> I'd like to document the policy clearly in the upgrade section of PostgreSQL
> manual, eliminating any ambiguity, so that users can determine what they
> should do without fear like "may or may not work". Which of the following
> po
> From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier
> On Fri, Jul 1, 2016 at 9:33 AM, Tsunakawa, Takayuki
> wrote:
> > [Q1]
> > Can the same UDF binary be used with different PostgreSQL minor releases?
> If it is, is it a defined po
On Fri, Jul 1, 2016 at 9:33 AM, Tsunakawa, Takayuki
wrote:
> [Q1]
> Can the same UDF binary be used with different PostgreSQL minor releases? If
> it is, is it a defined policy (e.g. written somewhere in the manual, wiki,
> documentation in the source code)?
>
> For example, suppose you build a
Hello,
While I was thinking of application binary compatibility between PostgreSQL
releases, some questions arose about C language user-defined functions (UDFs)
and extensions that depend on them.
[Q1]
Can the same UDF binary be used with different PostgreSQL minor releases? If
it is, is it a
12 matches
Mail list logo
