Stephen Frost writes:
> I'm not against this idea- but we *still* need to solve the problem of
> how we update the catalog during a point release and, imv anyway, we
> would need to be able to upgrade any in-core installed-by-default
> extensions during a point release too, to address any security
On 2013-05-06 14:34:52 +0200, Dimitri Fontaine wrote:
> In-core installed-by-default extensions, anyone?
We already have that in plpgsql ...
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
-
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
> Another advantage of using more the extension infrastructure is that
> shipping bug fixes in the C or SQL parts of them would allow a hot fix
> to be shipped without restart when limited to an extension.
I'm actually not thrilled with the securi
Stephen Frost writes:
> It likely is, but it would really be nice to be able to do catalog
> updates like these in a better fashion than sticking some update command
> into the release notes and hoping that someone reads them and runs the
> command..
Agreed.
Another advantage of using more the e
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
> Andres Freund writes:
> > Just a little collection of problems:
> > * You need to connect to all databases, not just one. There's no
> > infrastructure for this.
>
> I wonder if it wouldn't be possible to have a per database catalog
> version
Andres Freund writes:
> On 2013-04-30 05:14:15 +0100, Joel Jacobson wrote:
>> It would be better to find a way to update sql-language functions in
>> minor upgrades, instead of shutting that door entirely for all future
>> implementation ideas involving sql-language functions in the
>> pg_catalog.
On Tue, Apr 30, 2013 at 04:47:58AM +0100, Joel Jacobson wrote:
> On Tue, Apr 30, 2013 at 12:46 AM, Noah Misch wrote:
> > Those existing functions give a mostly-SnapshotNow picture of their objects,
> > but an sql-language implementation would give a normally-snapshotted
> > picture.
>
> I assume
On Tue, Apr 30, 2013 at 9:02 AM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> On Mon, Apr 29, 2013 at 7:58 PM, Tom Lane wrote:
>> > One of the things that we frequently recommend when doing
>> > upgrades is that you do the dump with the newer version's pg_dump, so
>> > a
On 2013-04-30 15:57:02 +0200, Andres Freund wrote:
> On 2013-04-30 05:14:15 +0100, Joel Jacobson wrote:
> > On Tue, Apr 30, 2013 at 12:58 AM, Tom Lane wrote:
> > > Noah Misch writes:
> > >> Note also that minor releases can readily fix bugs in C-language
> > >> functions,
> > >> but we have no i
Andrew Dunstan writes:
> If all you want is SQL language functions, there is nothing to stop you
> from writing them and publishing them today as an extension.
It's worth noting also that we actually *have* infrastructure for
updating extensions without initdb; unlike the initial contents of
pg_
On 2013-04-30 05:14:15 +0100, Joel Jacobson wrote:
> On Tue, Apr 30, 2013 at 12:58 AM, Tom Lane wrote:
> > Noah Misch writes:
> >> Note also that minor releases can readily fix bugs in C-language functions,
> >> but we have no infrastructure to update sql-language functions after
> >> initdb.
>
* Joel Jacobson (j...@trustly.com) wrote:
> Thanks for the motivational speech! :) I'll start working on it today!
Great, but you should really come up with an initial design and get
feedback on it before you start coding up something. :) I've outlined a
few very, very high-level ideas about what
On Tue, Apr 30, 2013 at 2:12 PM, Stephen Frost wrote:
> Go for it? :) I don't think you'll find much disagreement here, but
> it's no trivial thing to do either.. Perhaps some kind of one-time
> startup "script" that gets run? Or maybe an internal identifier that
> The above doesn't really see
* Joel Jacobson (j...@trustly.com) wrote:
> On Tue, Apr 30, 2013 at 12:58 AM, Tom Lane wrote:
> > That alone would probably be sufficient reason why we would never allow
> > pg_dump to depend on any such thing (not that I see a compelling
> > argument for it to do so anyway...).
>
> It would be b
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Apr 29, 2013 at 7:58 PM, Tom Lane wrote:
> > One of the things that we frequently recommend when doing
> > upgrades is that you do the dump with the newer version's pg_dump, so
> > as to get the benefits of any bug fixes that are in it. The m
Tom, all,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> It may be that the functions Joel proposes are worth having for other
> tools to use, but I'm not in favor of making pg_dump use them.
I care very little about migrating the pg_dump functionality into
server-side functions and a great deal about
On 04/30/2013 07:34 AM, Joel Jacobson wrote:
On Tue, Apr 30, 2013 at 11:22 AM, Andrew Dunstan wrote:
Minor releases are supposed not to require any such operations. You should
normally be able to drop the binaries in place and restart. For C language
functions that is indeed all you have to do
On Tue, Apr 30, 2013 at 11:22 AM, Andrew Dunstan wrote:
> Minor releases are supposed not to require any such operations. You should
> normally be able to drop the binaries in place and restart. For C language
> functions that is indeed all you have to do, but that's not the case for SQL
> languag
On 04/29/2013 11:47 PM, Joel Jacobson wrote:
Note also that minor releases can readily fix bugs in C-language functions,
but we have no infrastructure to update sql-language functions after initdb.
That flexibility is unfortunate to lose, particularly for something that
pg_dump depends on. Now,
On Tue, Apr 30, 2013 at 12:58 AM, Tom Lane wrote:
> Noah Misch writes:
>> Note also that minor releases can readily fix bugs in C-language functions,
>> but we have no infrastructure to update sql-language functions after initdb.
>> That flexibility is unfortunate to lose, particularly for someth
On Tue, Apr 30, 2013 at 12:46 AM, Noah Misch wrote:
> Note that while the sql procedural language is fair game, plpgsql currently is
> not. We install it by default, but the DBA is free to drop it.
Right. The "sql" procedural language was what I had in mind.
> Those existing functions give a mo
On Mon, Apr 29, 2013 at 7:58 PM, Tom Lane wrote:
> The long and the short of it here is that there isn't any very good
> reason to migrate any of the existing pg_dump-side functionality into
> server-side functions,
There are a number of good reasons to do just that, which have been
previous
Noah Misch writes:
> Note also that minor releases can readily fix bugs in C-language functions,
> but we have no infrastructure to update sql-language functions after initdb.
> That flexibility is unfortunate to lose, particularly for something that
> pg_dump depends on.
That alone would probabl
On Mon, Apr 29, 2013 at 10:16:22PM +0100, Joel Jacobson wrote:
> Existing:
>
> pg_get_constraintdef
> pg_get_indexdef
> pg_get_viewdef
> pg_get_triggerdef
> pg_get_functiondef
> pg_get_ruledef
>
> Missing:
>
> pg_get_ts_templatedef
> pg_get_ts_parserdef
> pg_get_ts_configdef
> pg_get_ts_dictdef
Existing:
pg_get_constraintdef
pg_get_indexdef
pg_get_viewdef
pg_get_triggerdef
pg_get_functiondef
pg_get_ruledef
Missing:
pg_get_ts_templatedef
pg_get_ts_parserdef
pg_get_ts_configdef
pg_get_ts_dictdef
pg_get_databasedef
pg_get_namespacedef
pg_get_languagedef
pg_get_conversiondef
pg_get_castdef
25 matches
Mail list logo
