hello ...
i have come an interesting corner case this morning and i am not sure
if it is worth treating this as a bug or as just "bad luck".
imagine creating a directory along with a tablespace ...
hans-jurgen-schonigs-macbook:html hs$ mkdir /tmp/x
hans-jurgen-schonigs-macbook:html hs$ psql te
On Wed, Feb 27, 2008 at 2:29 PM, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
> > You could just pull up a psql session and do a "select
> > pg_func_def(regproc);" and there you go, one fully formed CREATE
> > FUNCTION statement.
>
> \df+ function(type)
>
Sure, if your idea of a good time is lo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 27 Feb 2008 13:05:44 +1100
"Brendan Jurd" <[EMAIL PROTECTED]> wrote:
>
> You could just pull up a psql session and do a "select
> pg_func_def(regproc);" and there you go, one fully formed CREATE
> FUNCTION statement.
\df+ function(type)
Jo
On Tue, Feb 26, 2008 at 12:48 AM, David BOURIAUD
<[EMAIL PROTECTED]> wrote:
> I haven't found any option to dump any user-defined function stored in a
> database, unless doing a pg_dump -D -s database, but so far one would get the
> definitions of the tables, the permissions, the triggers, and s
On Mon, Feb 25, 2008 at 12:33 PM, David BOURIAUD
<[EMAIL PROTECTED]> wrote:
> Le lundi 25 février 2008, Leonardo Cezar a écrit :
>
> Hi Leonardo,
> Thanks for your quick answer, I didn't know it was a TODO item, and that
> somepeople were working on it... Keep going, then, cause I'm really waiti
Le lundi 25 février 2008, Leonardo Cezar a écrit :
Hi Leonardo,
Thanks for your quick answer, I didn't know it was a TODO item, and that
somepeople were working on it... Keep going, then, cause I'm really waiting
for these features !
> On Mon, Feb 25, 2008 at 10:48 AM, David BOURIAUD
>
> <[EMAI
On Mon, Feb 25, 2008 at 10:48 AM, David BOURIAUD
<[EMAIL PROTECTED]> wrote:
> Could there be an option to pg_dump (let's say --function [func_name]) to be
> abble to dump the complete source code of a function in a separate file, or
> on the terminal ?
It's a TODO item. Just not to functions an
Hi all,
On the 6th of february, there's been a thread about adding new options to
pg_dump, but it is now too late for me to add comments to this thread, since
all that was said wouldn't be readable at this time, so I add an new thread
here.
I haven't found any option to dump any user-defined fun
Hi,
I just talked to Sebastian again and we face another problem. The
software he's porting to PostgreSQL calls SQLProcedureColumns to get the
info about the input columns and the result. But the problem is that the
function in question returns an unnamed cursor. Before we start porting
the proce
to ignore ...
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
> > Did we decide against LAZY? Seems we have a number of people
> > concerned about vacuum downtime, and I can see this as a win
> > for them. If they don't specify LAZY, the code is not run.
>
> First sorry that I wasn't able to deal with vlazy earlier.
>
> Now I have one more open item for 7.1
> Did we decide against LAZY? Seems we have a number of people
> concerned about vacuum downtime, and I can see this as a win
> for them. If they don't specify LAZY, the code is not run.
First sorry that I wasn't able to deal with vlazy earlier.
Now I have one more open item for 7.1 - restoring
Bruce Momjian wrote:
>
> Did we decide against LAZY? Seems we have a number of people concerned
> about vacuum downtime, and I can see this as a win for them. If they
> don't specify LAZY, the code is not run.
I see a number of possibilities:
1.) A tested 'feature patch' available for sepa
On Wed, 24 Jan 2001, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Did we decide against LAZY?
>
> I thought the core consensus was that it was too risky to install
> post-beta. On the other hand, we're installing some other pretty
> major fixes. Do we want to re-open that dis
Did we decide against LAZY? Seems we have a number of people concerned
about vacuum downtime, and I can see this as a win for them. If they
don't specify LAZY, the code is not run.
> The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > should be easily testable though, no?
>
> What makes you thi
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Did we decide against LAZY?
I thought the core consensus was that it was too risky to install
post-beta. On the other hand, we're installing some other pretty
major fixes. Do we want to re-open that discussion?
regards, tom la
On Mon, Dec 11, 2000 at 11:32:17PM -0500, Tom Lane wrote:
> The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > worst case, we pull it out afterwards ...
>
> No, worst case is that we release a seriously broken 7.1, and don't
> find out till afterwards.
>
> There are plenty of new features on my t
* Andrew Snow <[EMAIL PROTECTED]> [001211 20:21] wrote:
>
> On Mon, 11 Dec 2000, Tom Lane wrote:
>
> > "Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> > > If there are no objections then I'm ready to add changes to 7.1.
> > > Else, I'll produce patches for 7.1 just after release and incorporate
>
On Mon, 11 Dec 2000, Tom Lane wrote:
> The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > should be easily testable though, no?
>
> What makes you think that?
Alfred could volunteer to move to v7.1? *grin*
The Hermit Hacker <[EMAIL PROTECTED]> writes:
> should be easily testable though, no?
What makes you think that?
> worst case, we pull it out afterwards ...
No, worst case is that we release a seriously broken 7.1, and don't
find out till afterwards.
There are plenty of new features on my to
> > I'd vote for the second choice. I do not think we should be adding new
> > features now. Also, I don't know about you, but I have enough bug fix,
> > testing, and documentation work to keep me busy till January even
> > without any new features...
>
> It'd be really naughty to add it to the
On Mon, 11 Dec 2000, Tom Lane wrote:
> The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > I'd almost extend that to the point that it is probably more tested right
> > now then any other feature that has been added to v7.1 pre-beta,
> > considering my knowledge of Alfred's environment ...
>
> And
On Mon, 11 Dec 2000, Tom Lane wrote:
> "Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> > If there are no objections then I'm ready to add changes to 7.1.
> > Else, I'll produce patches for 7.1 just after release and incorporate
> > changes into 7.2.
>
> I'd vote for the second choice. I do not
The Hermit Hacker <[EMAIL PROTECTED]> writes:
> I'd almost extend that to the point that it is probably more tested right
> now then any other feature that has been added to v7.1 pre-beta,
> considering my knowledge of Alfred's environment ...
And wasn't Alfred hollering yesterday about sudden in
Bruce Momjian <[EMAIL PROTECTED]> writes:
> But we just entered beta. Can't we let this slide? Seems like a nice
> feature. I can't image it delaying anything.
I can imagine it *breaking* lots of things.
We just today discovered that we didn't understand the interaction
between VACUUM and TOA
> A few points in favor of including this ... first, when Vadim does do the
> storage manager rewrite for v7.2, the patch is essentially useless ... and
> second, its currently being used in production on a server that is/will
> tax it heavily, so it isn't untested ...
>
> I'd almost extend that
On Mon, 11 Dec 2000, Tom Lane wrote:
> "Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> > If there are no objections then I'm ready to add changes to 7.1.
> > Else, I'll produce patches for 7.1 just after release and incorporate
> > changes into 7.2.
>
> I'd vote for the second choice. I do not t
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> If there are no objections then I'm ready to add changes to 7.1.
> Else, I'll produce patches for 7.1 just after release and incorporate
> changes into 7.2.
I'd vote for the second choice. I do not think we should be adding new
features now. Also,
Thanks. The other good item is that is already being used in production
use, so it seems it is pretty well tested.
>
> Go for it Vadim ... it is only a couple of days in, and I know there are
> several places I could personally use it ...
>
> On Mon, 11 Dec 2000, Bruce Momjian wrote:
>
> > >
Go for it Vadim ... it is only a couple of days in, and I know there are
several places I could personally use it ...
On Mon, 11 Dec 2000, Bruce Momjian wrote:
> > > If there are no objections then I'm ready to add changes to 7.1.
> > > Else, I'll produce patches for 7.1 just after release and
> > If there are no objections then I'm ready to add changes to 7.1.
> > Else, I'll produce patches for 7.1 just after release and incorporate
> > changes into 7.2.
> >
> > Comments?
>
> IMHO, we are in beta now and this doesn't fix a bug ... if we could make
> this available as a patch in /cont
On Mon, 11 Dec 2000, Mikheev, Vadim wrote:
> > > > If Vadim isn't sufficiently confident of it to commit it
> > > > on his own authority, I'm inclined to leave it out of 7.1.
> > > > My concern is mostly schedule. We are well into beta cycle
> > > > now and this seems like way too critical (not
> > > If Vadim isn't sufficiently confident of it to commit it
> > > on his own authority, I'm inclined to leave it out of 7.1.
> > > My concern is mostly schedule. We are well into beta cycle
> > > now and this seems like way too critical (not to say high-risk)
> > > a feature to be adding after
* The Hermit Hacker <[EMAIL PROTECTED]> [001211 14:27] wrote:
> On Mon, 11 Dec 2000, Bruce Momjian wrote:
>
> > > Alfred Perlstein <[EMAIL PROTECTED]> writes:
> > > > Basically Vadim left it up to me to campaign for acceptance of this
> > > > work and he said he wouldn't have a problem bringing i
On Mon, 11 Dec 2000, Bruce Momjian wrote:
> > Alfred Perlstein <[EMAIL PROTECTED]> writes:
> > > Basically Vadim left it up to me to campaign for acceptance of this
> > > work and he said he wouldn't have a problem bringing it in as long
> > > as it was ok with the rest of the development team.
>
On Mon, 11 Dec 2000, Tom Lane wrote:
> Alfred Perlstein <[EMAIL PROTECTED]> writes:
> > Basically Vadim left it up to me to campaign for acceptance of this
> > work and he said he wouldn't have a problem bringing it in as long
> > as it was ok with the rest of the development team.
> > So can we
> Alfred Perlstein <[EMAIL PROTECTED]> writes:
> > Basically Vadim left it up to me to campaign for acceptance of this
> > work and he said he wouldn't have a problem bringing it in as long
> > as it was ok with the rest of the development team.
> > So can we get a go-ahead on this? :)
>
> If Vad
Alfred Perlstein <[EMAIL PROTECTED]> writes:
> Basically Vadim left it up to me to campaign for acceptance of this
> work and he said he wouldn't have a problem bringing it in as long
> as it was ok with the rest of the development team.
> So can we get a go-ahead on this? :)
If Vadim isn't suffi
Sounds good to me. [Of course, I never met a patch I didn't like, or so
they say.]
> I know you guys are pretty busy with the upcoming release but I
> was hoping for more interest in this work.
>
> With this (which needs forward porting) we're able to cut
> vacuum time down from ~10minutes to
I know you guys are pretty busy with the upcoming release but I
was hoping for more interest in this work.
With this (which needs forward porting) we're able to cut
vacuum time down from ~10minutes to under 30 seconds.
The code is a nop unless you compile with special options(MMNB)
specify the s
40 matches
Mail list logo
