From: | "David E(dot) Wheeler" <david(at)kineticode(dot)com> |
---|---|
To: | Aidan Van Dyk <aidan(at)highrise(dot)ca> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org Hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Extension Packaging |
Date: | 2011-04-25 16:17:12 |
Message-ID: | CA8D96A7-7D1C-4091-A092-77BC977523BF@kineticode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Apr 25, 2011, at 9:14 AM, Aidan Van Dyk wrote:
> Really, that means you just a sql function to your extension,
> somethign similary to uname -a, or rpm -qi, which includes something
> that is *forced* to change the postgresql catalog view of your
> extension every time you ship a new version (major, or patch), and
> then you get the exact version (and whatever else you include) for
> free every time you update ;-)
I think it's silly for every extension to have its own function that does this. Every one would have a different name and, perhaps, signature.
> The thing to remember is that the postgresql "extensions" are managing
> the *postgresql catalogs* view of things, even though the shared
> object used by postgresql to provide the particular catalog's
> requirements can be "fixed".
>
> If your extension is almost exclusively a shared object, and the only
> catalog things are a couple of functions defined to point into the C
> code, there really isn't anything catalog-wise that you need to
> "manage" for upgrades.
Most of my extensions will not be written in C (e.g., pgTAP, explanation).
Best,
David
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-04-25 16:52:18 | Unfriendly handling of pg_hba SSL options with SSL off |
Previous Message | Alvaro Herrera | 2011-04-25 16:16:33 | Re: offline consistency check and info on attributes |