--- Den fre 2010-04-30 skrev Bruce Momjian :
> Tom Lane wrote:
> > Robert Haas
> writes:
> > > We can artificially make this problem as
> complicated as we wish, but
> > > the people who are asking for this feature
> (including me) will, I
> > > believe, be quite happy with a solution that
> throw
Robert Haas writes:
> On Sat, May 1, 2010 at 11:38 PM, Tom Lane wrote:
>> To the extent that future bug fixes are relevant to multiple versions
>> of pg_migrator, we could just apply them to multiple branches, same as
>> we manage such fixes for the core code. I don't see that trying to
>> have
On Sat, May 1, 2010 at 11:38 PM, Tom Lane wrote:
> To the extent that future bug fixes are relevant to multiple versions
> of pg_migrator, we could just apply them to multiple branches, same as
> we manage such fixes for the core code. I don't see that trying to
> have a single version of pg_migr
Andrew Dunstan writes:
> Robert Haas wrote:
>> I don't think it's going
>> to be practical to retain all the migration code for every pair of
>> versions forever,
> I thought the idea was just to support migration from version N to
> version N+1.
Yeah. I think trying to do more than that is j
On Sat, May 1, 2010 at 11:31 PM, Andrew Dunstan wrote:
> Robert Haas wrote:
>>
>> I don't think it's going
>> to be practical to retain all the migration code for every pair of
>> versions forever,
>
> I thought the idea was just to support migration from version N to version
> N+1.
I think that
Robert Haas wrote:
I don't think it's going
to be practical to retain all the migration code for every pair of
versions forever,
I thought the idea was just to support migration from version N to
version N+1.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgr
On Sat, May 1, 2010 at 5:46 PM, Bruce Momjian wrote:
>> > Agreed, we're not holding up 9.0 for it. I think the main bit of work
>> > that would be needed to put it into contrib would be to SGML-ize the
>> > docs. Don't know if Bruce has got the time to get that done.
>>
>> Creating the SGML docs
On Fri, Apr 30, 2010 at 10:38 AM, Tom Lane wrote:
> Scott Bailey writes:
>> Proposal: Add an invalid flag to pg_class. Invalid objects would be
>> ignored when doing dependency checks for DDL statements. And an
>> exception would be thrown when an invalid object is called.
>
> IMO, the way Oracle
On Wed, Apr 28, 2010 at 9:15 PM, Tom Lane wrote:
>> CREATE OR REPLACE is indeed much more complicated. In fact, for
>> tables, I maintain that you'll need to link with -ldwim to make it
>> work properly.
>
> This may in fact be an appropriate way to handle the case for tables,
> given the complex
C?dric Villemain wrote:
> 2010/5/1 Bruce Momjian :
> > Tom Lane wrote:
> >> Bruce Momjian writes:
> >> > While most of the limitations in previous versions of pg_migrator are
> >> > gone, there are still issues with migrating /contrib modules, and there
> >> > are many steps to its use.
> >>
> >>
2010/5/1 Bruce Momjian :
> Tom Lane wrote:
>> Bruce Momjian writes:
>> > While most of the limitations in previous versions of pg_migrator are
>> > gone, there are still issues with migrating /contrib modules, and there
>> > are many steps to its use.
>>
>> > I think to attain mass usage of pg_mig
> > Agreed, we're not holding up 9.0 for it. I think the main bit of work
> > that would be needed to put it into contrib would be to SGML-ize the
> > docs. Don't know if Bruce has got the time to get that done.
>
> Creating the SGML docs is trivial, especially compared to the 9.0
> release note
Tom Lane wrote:
> Robert Haas writes:
> > On Sat, May 1, 2010 at 11:42 AM, Tom Lane wrote:
> >> I think that having it in contrib for a release cycle or so would be
> >> exactly the right approach, actually. ?Peter's position that it should
> >> be in /bin is fine *once the bugs are out*. ?Just d
Tom Lane wrote:
> Bruce Momjian writes:
> > While most of the limitations in previous versions of pg_migrator are
> > gone, there are still issues with migrating /contrib modules, and there
> > are many steps to its use.
>
> > I think to attain mass usage of pg_migrator, some type of one-click
Robert Haas writes:
> On Sat, May 1, 2010 at 11:42 AM, Tom Lane wrote:
>> I think that having it in contrib for a release cycle or so would be
>> exactly the right approach, actually. Peter's position that it should
>> be in /bin is fine *once the bugs are out*. Just dropping it there
>> doesn'
Bruce Momjian writes:
> While most of the limitations in previous versions of pg_migrator are
> gone, there are still issues with migrating /contrib modules, and there
> are many steps to its use.
> I think to attain mass usage of pg_migrator, some type of one-click
> installer has to be built
> I think the big question is whether we want to provide a binary upgrade
> facility for Postgres. If so, pg_migrator is the only facility
> currently available, and I can't imagine another option appearing. I
> would love for pg_migrator to be easier to use, but I can't figure out
> how that can
Robert Haas wrote:
> On Sat, May 1, 2010 at 11:42 AM, Tom Lane wrote:
> > Robert Haas writes:
> >> On Sat, May 1, 2010 at 3:32 AM, Magnus Hagander
> >> wrote:
> >>> A lot of people are not willing to put stuff labeled "contrib" on
> >>> their production boxes.
> >>>
> >>> And as Tom says, even
On Sat, May 1, 2010 at 11:42 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Sat, May 1, 2010 at 3:32 AM, Magnus Hagander wrote:
>>> A lot of people are not willing to put stuff labeled "contrib" on
>>> their production boxes.
>>>
>>> And as Tom says, even we *ourselves* acknowledge that things
Tom Lane wrote:
> Robert Haas writes:
> > On Sat, May 1, 2010 at 3:32 AM, Magnus Hagander wrote:
> >> A lot of people are not willing to put stuff labeled "contrib" on
> >> their production boxes.
> >>
> >> And as Tom says, even we *ourselves* acknowledge that things in
> >> /contrib are held to
On Sat, May 1, 2010 at 2:26 PM, Kjell Rune Skaaraas wrote:
> In other words, pretty much all the hard bits I seem to hear people agree
> on exist still apply to the single column. COR for columns was suggested
> already back in the same thread in 2005:
>
> http://archives.postgresql.org/pgsql-hack
On Sat, 2010-05-01 at 13:12 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > On Sat, 2010-05-01 at 12:37 -0400, Tom Lane wrote:
> >> Where is this test procedure documented?
>
> > In src/test/regress/standby_schedule
>
> That's a good way to ensure nobody knows it's there :-(
>
> If you want us
Simon Riggs writes:
> On Sat, 2010-05-01 at 12:37 -0400, Tom Lane wrote:
>> Where is this test procedure documented?
> In src/test/regress/standby_schedule
That's a good way to ensure nobody knows it's there :-(
If you want users to run this, document it in cookbook fashion in
doc/src/sgml/regr
On Sat, 2010-05-01 at 12:37 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > On Sat, 2010-05-01 at 09:05 -0500, Jaime Casanova wrote:
> >> maybe we should be using the tables that exists in the regression
> >> database or adding hs_setup_primary in installcheck to prepare the
> >> regression datab
Simon Riggs writes:
> On Sat, 2010-05-01 at 09:05 -0500, Jaime Casanova wrote:
>> maybe we should be using the tables that exists in the regression
>> database or adding hs_setup_primary in installcheck to prepare the
>> regression database to run standbycheck in the standby server
> That's part
On Sat, May 1, 2010 at 12:01 PM, Tom Lane wrote:
> The thread here
> http://archives.postgresql.org/pgsql-admin/2010-04/msg00358.php
> shows that current OS X contains the same issue that was complained of
> a year or so ago with respect to NetBSD. Namely, that if shmget finds
> an existing share
The thread here
http://archives.postgresql.org/pgsql-admin/2010-04/msg00358.php
shows that current OS X contains the same issue that was complained of
a year or so ago with respect to NetBSD. Namely, that if shmget finds
an existing shared memory segment that is smaller than the current
request, i
Robert Haas writes:
> On Sat, May 1, 2010 at 3:32 AM, Magnus Hagander wrote:
>> A lot of people are not willing to put stuff labeled "contrib" on
>> their production boxes.
>>
>> And as Tom says, even we *ourselves* acknowledge that things in
>> /contrib are held to a lower standard. If we put t
On Sat, 2010-05-01 at 09:05 -0500, Jaime Casanova wrote:
> maybe we should be using the tables that exists in the regression
> database or adding hs_setup_primary in installcheck to prepare the
> regression database to run standbycheck in the standby server
That's part of the procedure already.
On Sat, May 1, 2010 at 7:22 AM, Simon Riggs wrote:
> On Mon, 2010-04-26 at 02:45 -0500, Jaime Casanova wrote:
>> On Mon, Apr 26, 2010 at 2:32 AM, Heikki Linnakangas
>> wrote:
>> >
>> > How many of the tests in the regular regression suite do anything useful
>> > when run against a standby server?
On Mon, 2010-04-26 at 02:45 -0500, Jaime Casanova wrote:
> On Mon, Apr 26, 2010 at 2:32 AM, Heikki Linnakangas
> wrote:
> >
> > How many of the tests in the regular regression suite do anything useful
> > when run against a standby server? They all have to set up a bunch of
> > objects before they
On Sat, May 1, 2010 at 3:32 AM, Magnus Hagander wrote:
> On Sat, May 1, 2010 at 02:23, Bruce Momjian wrote:
>> Tom Lane wrote:
>>> Dimitri Fontaine writes:
>>> > Peter Eisentraut writes:
>>> >> I also think that the standards for contrib should not be so lax that a
>>> >> completely new module
Hi,
Bruce Momjian írta:
> Please add it to the next commit-fest:
>
> https://commitfest.postgresql.org/action/commitfest_view/inprogress
>
it was already added two days ago:
https://commitfest.postgresql.org/action/patch_view?id=297
Best regards,
Zoltán Böszörményi
--
Bible has answe
On Sat, May 1, 2010 at 02:23, Bruce Momjian wrote:
> Tom Lane wrote:
>> Dimitri Fontaine writes:
>> > Peter Eisentraut writes:
>> >> I also think that the standards for contrib should not be so lax that a
>> >> completely new module can be added after beta. (This is mostly informed
>> >> by the
34 matches
Mail list logo
