Hi there,
Refering to https://www.postgresql.org/message-id/1352742344.21373.4@mofo
I'm running into situations where I'd need to bulk transfer of data
tables across servers, but a drop and recreate schema isn't feasible
as we are running different permissions etc. on the two databases.
Thus
On Nov 28, 2013, at 5:18 PM, Bruce Momjian wrote:
> On Thu, Nov 28, 2013 at 04:51:14PM -0500, Robert Haas wrote:
>> On Wed, Nov 27, 2013 at 4:44 PM, Bruce Momjian wrote:
Seems broadly reasonable, but I'd use "no other effect" throughout.
>>>
>>> That sounds awkward, e.g.:
>>>
>>> Issui
On Thu, Nov 28, 2013 at 04:51:14PM -0500, Robert Haas wrote:
> On Wed, Nov 27, 2013 at 4:44 PM, Bruce Momjian wrote:
> >> Seems broadly reasonable, but I'd use "no other effect" throughout.
> >
> > That sounds awkward, e.g.:
> >
> > Issuing ROLLBACK outside of a transaction
> > block emi
On Wed, Nov 27, 2013 at 4:44 PM, Bruce Momjian wrote:
>> Seems broadly reasonable, but I'd use "no other effect" throughout.
>
> That sounds awkward, e.g.:
>
> Issuing ROLLBACK outside of a transaction
> block emits a warning but has no other effect.
>
> I could live with this:
>
>
On Wed, Nov 27, 2013 at 04:44:02PM -0500, Bruce Momjian wrote:
> I could live with this:
>
> Issuing ROLLBACK outside of a transaction
> block has no effect except emitting a warning.
Proposed doc patch attached.
--
Bruce Momjian http://momjian.us
EnterpriseDB
On Wed, Nov 27, 2013 at 03:59:31PM -0500, Robert Haas wrote:
> On Tue, Nov 26, 2013 at 5:02 PM, Bruce Momjian wrote:
> > On Tue, Nov 26, 2013 at 01:58:04PM -0300, Alvaro Herrera wrote:
> >> Bruce Momjian escribió:
> >> > On Tue, Nov 26, 2013 at 11:22:39AM -0500, Tom Lane wrote:
> >>
> >> > > > Uh,
On Tue, Nov 26, 2013 at 5:02 PM, Bruce Momjian wrote:
> On Tue, Nov 26, 2013 at 01:58:04PM -0300, Alvaro Herrera wrote:
>> Bruce Momjian escribió:
>> > On Tue, Nov 26, 2013 at 11:22:39AM -0500, Tom Lane wrote:
>>
>> > > > Uh, I ended up mentioning "no effect" to highlight it does nothing,
>> > > >
On Tue, Nov 26, 2013 at 01:58:04PM -0300, Alvaro Herrera wrote:
> Bruce Momjian escribió:
> > On Tue, Nov 26, 2013 at 11:22:39AM -0500, Tom Lane wrote:
>
> > > > Uh, I ended up mentioning "no effect" to highlight it does nothing,
> > > > rather than mention a warning. Would people prefer I say "w
Bruce Momjian escribió:
> On Tue, Nov 26, 2013 at 11:22:39AM -0500, Tom Lane wrote:
> > > Uh, I ended up mentioning "no effect" to highlight it does nothing,
> > > rather than mention a warning. Would people prefer I say "warning"? Or
> > > should I say "issues a warning because it has no effect
On Tue, Nov 26, 2013 at 11:22:39AM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > On Mon, Nov 25, 2013 at 10:04:19PM -0500, Robert Haas wrote:
> >> But the documentation says:
> >>
> >> - Issuing ABORT when not inside a transaction does
> >> - no harm, but it will provoke a warning messag
Bruce Momjian writes:
> On Mon, Nov 25, 2013 at 10:04:19PM -0500, Robert Haas wrote:
>> But the documentation says:
>>
>> - Issuing ABORT when not inside a transaction does
>> - no harm, but it will provoke a warning message.
>> + Issuing ABORT outside of a transaction block has no effect.
On Mon, Nov 25, 2013 at 10:12:43PM -0500, Bruce Momjian wrote:
> > Those things are not the same.
>
> Uh, I ended up mentioning "no effect" to highlight it does nothing,
> rather than mention a warning. Would people prefer I say "warning"? Or
> should I say "issues a warning because it has no ef
On Mon, Nov 25, 2013 at 10:04:19PM -0500, Robert Haas wrote:
> On Mon, Nov 25, 2013 at 7:19 PM, Bruce Momjian wrote:
> > On Fri, Nov 22, 2013 at 01:19:55PM -0500, Bruce Momjian wrote:
> >> On Fri, Nov 22, 2013 at 12:17:41PM -0500, Bruce Momjian wrote:
> >> > Good points. I have modified the attac
On Mon, Nov 25, 2013 at 7:19 PM, Bruce Momjian wrote:
> On Fri, Nov 22, 2013 at 01:19:55PM -0500, Bruce Momjian wrote:
>> On Fri, Nov 22, 2013 at 12:17:41PM -0500, Bruce Momjian wrote:
>> > Good points. I have modified the attached patch to do as you suggested.
>>
>> Also, I have read through the
On Fri, Nov 22, 2013 at 01:19:55PM -0500, Bruce Momjian wrote:
> On Fri, Nov 22, 2013 at 12:17:41PM -0500, Bruce Momjian wrote:
> > Good points. I have modified the attached patch to do as you suggested.
>
> Also, I have read through the thread and summarized the positions of the
> posters:
>
>
On Fri, Nov 22, 2013 at 12:17:41PM -0500, Bruce Momjian wrote:
> Good points. I have modified the attached patch to do as you suggested.
Also, I have read through the thread and summarized the positions of the
posters:
9.3 WARNING ERROR
SET
On Fri, Nov 22, 2013 at 10:24:35AM -0300, Alvaro Herrera wrote:
> Bruce Momjian escribió:
>
> > OK, here is a patch which changes ABORT from NOTICE to WARNING, and SET
> > from ERROR (which is new in 9.4) to WARNING.
>
> I don't like that this patch changes RequireTransactionChain() from
> actual
Bruce Momjian escribió:
> OK, here is a patch which changes ABORT from NOTICE to WARNING, and SET
> from ERROR (which is new in 9.4) to WARNING.
I don't like that this patch changes RequireTransactionChain() from
actually requiring one, to a function that maybe requires a transaction
chain, and m
Robert Haas wrote:
> Well, Tom and I are on opposite sides of this, I suppose. I
> prefer ERROR for everything other than the top-level transaction
> commands, and see no benefit from opting for a wishy-washy
> warning.
+1
If the user issued a local command outside of a transaction there
is an
On Wed, Nov 20, 2013 at 04:31:12PM -0500, Robert Haas wrote:
> On Wed, Nov 20, 2013 at 4:19 PM, Bruce Momjian wrote:
> > On Wed, Nov 20, 2013 at 10:16:00AM -0500, Bruce Momjian wrote:
> >> > > The attached patch changes ABORT from NOTICE to WARNING, and documents
> >> > > that all other are errors
On Wed, Nov 20, 2013 at 4:19 PM, Bruce Momjian wrote:
> On Wed, Nov 20, 2013 at 10:16:00AM -0500, Bruce Momjian wrote:
>> > > The attached patch changes ABORT from NOTICE to WARNING, and documents
>> > > that all other are errors. This "top-level" logic idea came from Robert
>> > > Haas, and it h
On Wed, Nov 20, 2013 at 10:16:00AM -0500, Bruce Momjian wrote:
> > > The attached patch changes ABORT from NOTICE to WARNING, and documents
> > > that all other are errors. This "top-level" logic idea came from Robert
> > > Haas, and it has some level of consistency.
> >
> > This patch utterly fa
On Wed, Nov 20, 2013 at 10:04:22AM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > On Tue, Nov 19, 2013 at 10:21:47PM -0500, Tom Lane wrote:
> >> My personal standpoint is that I don't care much whether these messages
> >> are NOTICE or WARNING. What I'm not happy about is promoting cases that
Bruce Momjian writes:
> On Tue, Nov 19, 2013 at 10:21:47PM -0500, Tom Lane wrote:
>> My personal standpoint is that I don't care much whether these messages
>> are NOTICE or WARNING. What I'm not happy about is promoting cases that
>> have been non-error conditions for years into ERRORs.
> I don
On Tue, Nov 19, 2013 at 10:21:47PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > Does anyone know if this C comment justifies why ABORT is a NOTICE and
> > not WARNING?
>
> > /*
> > * The user issued ABORT when not inside a transaction. Issue a
> > * NOT
Bruce Momjian writes:
> Does anyone know if this C comment justifies why ABORT is a NOTICE and
> not WARNING?
> /*
> * The user issued ABORT when not inside a transaction. Issue a
> * NOTICE and go to abort state. The upcoming call to
> * Commit
Andres Freund writes:
> On 2013-11-19 13:09:16 -0500, Bruce Momjian wrote:
>> Because as Tom stated, we already do warnings for other useless
>> transaction commands like BEGIN WORK inside a transaction block:
>
> Which imo is a bad, bad historical accident. I've repeatedly seen this
> hide bugs c
On Tue, Nov 19, 2013 at 01:37:56PM -0500, Bruce Momjian wrote:
> On Tue, Nov 19, 2013 at 01:31:55PM -0500, Bruce Momjian wrote:
> > On Tue, Nov 19, 2013 at 01:20:47PM -0500, Robert Haas wrote:
> > > I think the pattern is and should be different for toplevel
> > > transaction control commands than
On Tue, Nov 19, 2013 at 01:31:55PM -0500, Bruce Momjian wrote:
> On Tue, Nov 19, 2013 at 01:20:47PM -0500, Robert Haas wrote:
> > I think the pattern is and should be different for toplevel
> > transaction control commands than for other things. If you issue a
> > BEGIN, we want it to end up that
On Tue, Nov 19, 2013 at 01:20:47PM -0500, Robert Haas wrote:
> I think the pattern is and should be different for toplevel
> transaction control commands than for other things. If you issue a
> BEGIN, we want it to end up that you're definitely in a transaction at
> that point, and if you issue a
On Tue, Nov 19, 2013 at 1:14 PM, Bruce Momjian wrote:
> On Tue, Nov 19, 2013 at 07:12:32PM +0100, Andres Freund wrote:
>> On 2013-11-19 13:09:16 -0500, Bruce Momjian wrote:
>> > > Why change the historical behaviour for savepoints?
>> >
>> > Because as Tom stated, we already do warnings for other
On 2013-11-19 13:14:34 -0500, Bruce Momjian wrote:
> On Tue, Nov 19, 2013 at 07:12:32PM +0100, Andres Freund wrote:
> > But even if that weren't a concern, the fact that BEGIN does it one way
> > currently doesn't seem very indicative of changing other historical
> > behaviour.
>
> Look at this g
On Tue, Nov 19, 2013 at 07:12:32PM +0100, Andres Freund wrote:
> On 2013-11-19 13:09:16 -0500, Bruce Momjian wrote:
> > > Why change the historical behaviour for savepoints?
> >
> > Because as Tom stated, we already do warnings for other useless
> > transaction commands like BEGIN WORK inside a tr
On 2013-11-19 13:09:16 -0500, Bruce Momjian wrote:
> > Why change the historical behaviour for savepoints?
>
> Because as Tom stated, we already do warnings for other useless
> transaction commands like BEGIN WORK inside a transaction block:
Which imo is a bad, bad historical accident. I've repea
On Tue, Nov 19, 2013 at 1:05 PM, Bruce Momjian wrote:
> A patch to issue only warnings is attached. In a way this change
> improves the code by throwing errors only when the commands are invalid,
> rather than just useless. You could argue that ROLLBACK TO SAVEPOINT
> should throw an error becau
On Tue, Nov 19, 2013 at 07:08:05PM +0100, Andres Freund wrote:
> On 2013-11-19 13:05:01 -0500, Bruce Momjian wrote:
> > SAVEPOINT
>
> > test=> ROLLBACK TO SAVEPOINT asdf;
> > ERROR: ROLLBACK TO SAVEPOINT can only be used in transaction blocks
> >
> > Notice that they do _not_ check t
On 2013-11-19 13:05:01 -0500, Bruce Momjian wrote:
> SAVEPOINT
> test=> ROLLBACK TO SAVEPOINT asdf;
> ERROR: ROLLBACK TO SAVEPOINT can only be used in transaction blocks
>
> Notice that they do _not_ check their arguments; they just throw
> errors. With this patch they issue
On Sat, Nov 9, 2013 at 02:15:52PM -0500, Robert Haas wrote:
> On Fri, Nov 8, 2013 at 5:36 PM, Tom Lane wrote:
> > [ I'm so far behind ... ]
> >
> > Bruce Momjian writes:
> >> Applied. Thank you for all your suggestions.
> >
> > I thought the suggestion had been to issue a *warning*. How did th
On Sat, Nov 9, 2013 at 02:15:52PM -0500, Robert Haas wrote:
> On Fri, Nov 8, 2013 at 5:36 PM, Tom Lane wrote:
> > [ I'm so far behind ... ]
> >
> > Bruce Momjian writes:
> >> Applied. Thank you for all your suggestions.
> >
> > I thought the suggestion had been to issue a *warning*. How did th
On Fri, Nov 8, 2013 at 5:36 PM, Tom Lane wrote:
> [ I'm so far behind ... ]
>
> Bruce Momjian writes:
>> Applied. Thank you for all your suggestions.
>
> I thought the suggestion had been to issue a *warning*. How did that
> become an error? This patch seems likely to break applications that
>
[ I'm so far behind ... ]
Bruce Momjian writes:
> Applied. Thank you for all your suggestions.
I thought the suggestion had been to issue a *warning*. How did that
become an error? This patch seems likely to break applications that
may have just been harmlessly sloppy about when they were iss
On Fri, Oct 4, 2013 at 09:40:38AM +0530, Amit Kapila wrote:
> On Thu, Oct 3, 2013 at 8:35 PM, Andres Freund wrote:
> > On 2013-09-30 22:19:31 -0400, Bruce Momjian wrote:
> >> On Sun, Sep 29, 2013 at 11:40:51AM +0530, Amit Kapila wrote:
> >> > >> Shouldn't we do it for Set Constraints as well?
> >
On Thu, Oct 3, 2013 at 8:32 PM, Bruce Momjian wrote:
> On Thu, Oct 3, 2013 at 11:50:09AM +0530, Amit Kapila wrote:
>> > I looked at this but could not see how to easily pass the value of
>> > 'isTopLevel' down to the SELECT. All the other checks have isTopLevel
>> > passed down from the utility
On Thu, Oct 3, 2013 at 8:35 PM, Andres Freund wrote:
> On 2013-09-30 22:19:31 -0400, Bruce Momjian wrote:
>> On Sun, Sep 29, 2013 at 11:40:51AM +0530, Amit Kapila wrote:
>> > >> Shouldn't we do it for Set Constraints as well?
>> > >
>> > > Oh, very good point. I missed that one. Updated patch at
On 2013-09-30 22:19:31 -0400, Bruce Momjian wrote:
> On Sun, Sep 29, 2013 at 11:40:51AM +0530, Amit Kapila wrote:
> > >> Shouldn't we do it for Set Constraints as well?
> > >
> > > Oh, very good point. I missed that one. Updated patch attached.
>
> I am glad you are seeing things I am not. :-)
On Thu, Oct 3, 2013 at 11:50:09AM +0530, Amit Kapila wrote:
> > I looked at this but could not see how to easily pass the value of
> > 'isTopLevel' down to the SELECT. All the other checks have isTopLevel
> > passed down from the utility case statement.
>
> Yes, we cannot pass isTopLevel, but as
On Tue, Oct 1, 2013 at 7:49 AM, Bruce Momjian wrote:
> On Sun, Sep 29, 2013 at 11:40:51AM +0530, Amit Kapila wrote:
>> >> Shouldn't we do it for Set Constraints as well?
>> >
>> > Oh, very good point. I missed that one. Updated patch attached.
>
> I am glad you are seeing things I am not. :-)
>
On Sun, Sep 29, 2013 at 11:40:51AM +0530, Amit Kapila wrote:
> >> Shouldn't we do it for Set Constraints as well?
> >
> > Oh, very good point. I missed that one. Updated patch attached.
I am glad you are seeing things I am not. :-)
> 1. The function set_config also needs similar functionality,
On Wed, Sep 25, 2013 at 2:55 AM, Bruce Momjian wrote:
> On Thu, Sep 12, 2013 at 09:38:43AM +0530, Amit Kapila wrote:
>> > I have created the attached patch which issues an error when SET
>> > TRANSACTION and SET LOCAL are used outside of transactions:
>> >
>> > test=> set transaction isola
On Thu, Sep 12, 2013 at 09:38:43AM +0530, Amit Kapila wrote:
> > I have created the attached patch which issues an error when SET
> > TRANSACTION and SET LOCAL are used outside of transactions:
> >
> > test=> set transaction isolation level serializable;
> > ERROR: SET TRANSACTION
On Wed, Sep 11, 2013 at 4:19 AM, Bruce Momjian wrote:
> On Sun, Feb 3, 2013 at 07:19:14AM +, Amit kapila wrote:
>>
>> On Saturday, February 02, 2013 9:08 PM Robert Haas wrote:
>> On Fri, Feb 1, 2013 at 12:04 AM, Amit Kapila wrote:
>> >> I think user should be aware of effect before using SET
On Sun, Feb 3, 2013 at 07:19:14AM +, Amit kapila wrote:
>
> On Saturday, February 02, 2013 9:08 PM Robert Haas wrote:
> On Fri, Feb 1, 2013 at 12:04 AM, Amit Kapila wrote:
> >> I think user should be aware of effect before using SET commands, as these
> >> are used at various levels (TRANSA
Wow.. thanks guys, really appreciate the detailed analysis.
Tim
On Wed, Jul 24, 2013 at 4:08 AM, Noah Misch wrote:
> On Tue, Jul 23, 2013 at 01:06:26PM +0100, Tim Kane wrote:
> > I haven't given this a lot of thought, but it struck me that when
> > rebuilding tables (be it for a restore proces
On 2013-07-23 14:17:13 +0100, Greg Stark wrote:
> We already do this in pg_restore by starting multiple worker processes.
> Those processes should get the benefit of synchronised sequential scans.
>
> The way the api for indexes works y wouldn't really be hard to start
> multiple parallel index bu
We already do this in pg_restore by starting multiple worker processes.
Those processes should get the benefit of synchronised sequential scans.
The way the api for indexes works y wouldn't really be hard to start
multiple parallel index builds. I'm not sure how well the pg_restore thing
works and
On Saturday, February 02, 2013 9:08 PM Robert Haas wrote:
On Fri, Feb 1, 2013 at 12:04 AM, Amit Kapila wrote:
>> I think user should be aware of effect before using SET commands, as these
>> are used at various levels (TRANSACTION, SESSION, ...).
> Ideally, sure. But these kinds of mistakes ar
On Fri, Feb 1, 2013 at 12:04 AM, Amit Kapila wrote:
> I think user should be aware of effect before using SET commands, as these
> are used at various levels (TRANSACTION, SESSION, ...).
Ideally, sure. But these kinds of mistakes are easy to make. That's
why LOCK and DECLARE CURSOR already emi
On Wednesday, January 30, 2013 6:53 AM Morten Hustveit wrote:
> Hi!
>
> Calling "SET TRANSACTION ISOLATION LEVEL ..." outside a transaction
> block has no effect. This is unlike "LOCK ..." and "DECLARE foo
> CURSOR FOR ...", which both raise an error. This is also unlike
> MySQL, where such a st
On 12/04/2012 09:26:47 PM, Josh Kupershmidt wrote:
> Sorry for the delay in following up here.
No problem at all.
> Well, as far as I was able to tell, the use-case where this patch
> worked without trouble was limited to restoring a table, or schema
> with table(s), that:
> a.) has some view(s)
Sorry for the delay in following up here.
On Mon, Nov 26, 2012 at 8:30 PM, Karl O. Pinc wrote:
> On 11/26/2012 08:45:08 PM, Josh Kupershmidt wrote:
>> On Mon, Nov 26, 2012 at 3:42 PM, Robert Haas
>> wrote:
>> > On Mon, Nov 26, 2012 at 4:51 PM, Karl O. Pinc wrote:
>> >> P.S. An outstanding ques
On 11/26/2012 09:30:48 PM, Karl O. Pinc wrote:
> On 11/26/2012 08:45:08 PM, Josh Kupershmidt wrote:
> > It is a common administrative task to selectively restore some
> > existing tables' contents from a backup, and IIRC was the impetus
> for
> > this patch.
>
> Yes. (And aside from listing tabl
On 11/26/2012 08:45:08 PM, Josh Kupershmidt wrote:
> On Mon, Nov 26, 2012 at 3:42 PM, Robert Haas
> wrote:
> > On Mon, Nov 26, 2012 at 4:51 PM, Karl O. Pinc wrote:
> >> P.S. An outstanding question regards --truncate-tables
> >> is whether it should drop indexes before truncate
> >> and re-creat
On Mon, Nov 26, 2012 at 3:42 PM, Robert Haas wrote:
> On Mon, Nov 26, 2012 at 4:51 PM, Karl O. Pinc wrote:
>> P.S. An outstanding question regards --truncate-tables
>> is whether it should drop indexes before truncate
>> and re-create them after restore. Sounds like it should.
>
> Well, that wo
On Mon, Nov 26, 2012 at 4:51 PM, Karl O. Pinc wrote:
> Where I would like to go with this is to first introduce,
> as a new patch, an ALTER TABLE option to disable a
> constraint. Something like
>
> ALTER TABLE foo UNVALIDATE CONSTRAINT "constraintname";
This doesn't really make sense, because
On 11/26/2012 12:06:56 PM, Robert Haas wrote:
> On Wed, Nov 21, 2012 at 12:53 AM, Josh Kupershmidt
> wrote:
> > TBH, I didn't find the example above particularly compelling for
> > demonstrating the need for this feature. If you've just got one
> table
> > with dependent views which needs to be re
On Wed, Nov 21, 2012 at 12:53 AM, Josh Kupershmidt wrote:
> TBH, I didn't find the example above particularly compelling for
> demonstrating the need for this feature. If you've just got one table
> with dependent views which needs to be restored, it's pretty easy to
> manually TRUNCATE and have p
On Wed, Nov 21, 2012 at 5:48 AM, Karl O. Pinc wrote:
>> On Fri, Sep 21, 2012 at 8:54 AM, Karl O. Pinc wrote:
>> > On 09/20/2012 12:24:49 PM, Karl O. Pinc wrote:
> OT:
> After looking at the code I found a number of "conflicting"
> option combinations are not tested for or rejected. I can't
>
Hi Josh,
On 11/20/2012 11:53:23 PM, Josh Kupershmidt wrote:
> Hi Karl,
> I signed on to review this patch for the current CF.
I noticed. Thanks very much.
> On Fri, Sep 21, 2012 at 8:54 AM, Karl O. Pinc wrote:
> > On 09/20/2012 12:24:49 PM, Karl O. Pinc wrote:
> > First, the problem:
> >
> >
Hi Karl,
I signed on to review this patch for the current CF. Most of the
background for the patch seems to be in the message below, so I'm
going to respond to this one first.
On Fri, Sep 21, 2012 at 8:54 AM, Karl O. Pinc wrote:
> On 09/20/2012 12:24:49 PM, Karl O. Pinc wrote:
>
>> I've had probl
Hi,
Attached is version 4. Version 3 no longer
built against head.
On 10/16/2012 09:48:06 PM, Karl O. Pinc wrote:
>
> On 09/23/2012 08:52:07 PM, Karl O. Pinc wrote:
>
> > On 09/23/2012 12:24:27 AM, Karl O. Pinc wrote:
>
> > > On 09/23/2012 12:19:07 AM, Karl O. Pinc wrote:
> > > > On 09/21/201
Hi,
Attached is version 3.
The convention seems to be to leave the operator at the
end of the line when breaking long lines, so do that.
Add extra () -- make operator precedence explicit and
have indentation reflect operator precedence.
On 09/23/2012 08:52:07 PM, Karl O. Pinc wrote:
> On 09/23/
Attached is version 2. The sgml did not build.
On 09/23/2012 12:24:27 AM, Karl O. Pinc wrote:
> Whoops. Do over. Sent the wrong file.
>
> On 09/23/2012 12:19:07 AM, Karl O. Pinc wrote:
> > On 09/21/2012 10:54:05 AM, Karl O. Pinc wrote:
> > > On 09/20/2012 12:24:49 PM, Karl O. Pinc wrote:
> > >
Whoops. Do over. Sent the wrong file.
On 09/23/2012 12:19:07 AM, Karl O. Pinc wrote:
> On 09/21/2012 10:54:05 AM, Karl O. Pinc wrote:
> > On 09/20/2012 12:24:49 PM, Karl O. Pinc wrote:
> >
> > > I've had problems using pg_restore --data-only when
> > > restoring individual schemas (which contai
On 09/21/2012 10:54:05 AM, Karl O. Pinc wrote:
> On 09/20/2012 12:24:49 PM, Karl O. Pinc wrote:
>
> > I've had problems using pg_restore --data-only when
> > restoring individual schemas (which contain data which
> > has had bad things done to it). --clean does not work
> > well because of depend
On 09/20/2012 12:24:49 PM, Karl O. Pinc wrote:
> I've had problems using pg_restore --data-only when
> restoring individual schemas (which contain data which
> has had bad things done to it). --clean does not work
> well because of dependent objects in other schemas.
Before doing any more work I
On Wednesday 09 September 2009 14:11:41 Peter Eisentraut wrote:
> On Thu, 2009-09-03 at 10:35 +0200, Ľubomír Varga wrote:
> > Hi.
> >
> > I hope, that this is right mailing list.
> >
> > SELECT date, value FROM t_event
> > WHERE t_event.id in (SELECT id FROM t_event
> > WHERE date <
On Thu, 2009-09-03 at 10:35 +0200, Ľubomír Varga wrote:
> Hi.
>
> I hope, that this is right mailing list.
>
> SELECT date, value FROM t_event
> WHERE t_event.id in (SELECT id FROM t_event
> WHERE date < '2009-08-25'
> ORDER BY date DESC LIMIT 1)
> ORDER BY
Chuck McDevitt wrote:
>>> Many of us would like to see libedit ported to Windows too ;-)
>> Yeah, it's on my (insanely long) TODO to look at sometime :-)
>>
>> //Magnus
>
> I've thought about working on a libedit port myself, but I don't see how
> that would help PostgreSQL unless the PostgreSQL c
Chuck McDevitt wrote:
> > >
> > > Many of us would like to see libedit ported to Windows too ;-)
> >
> > Yeah, it's on my (insanely long) TODO to look at sometime :-)
> >
> > //Magnus
>
> I've thought about working on a libedit port myself, but I don't see how
> that would help PostgreSQL unless
Chuck McDevitt wrote:
Many of us would like to see libedit ported to Windows too ;-)
Yeah, it's on my (insanely long) TODO to look at sometime :-)
//Magnus
I've thought about working on a libedit port myself, but I don't see how
that would help PostgreSQL unless the PostgreSQL c
> >
> > Many of us would like to see libedit ported to Windows too ;-)
>
> Yeah, it's on my (insanely long) TODO to look at sometime :-)
>
> //Magnus
I've thought about working on a libedit port myself, but I don't see how
that would help PostgreSQL unless the PostgreSQL community would be
willi
On Tue, Sep 25, 2007 at 06:09:36AM -0400, Andrew Dunstan wrote:
>
>
> Magnus Hagander wrote:
> >Can you check if your manually linked version works in non-US locales? If
> >you can't check, can you email me (offlist) with the binary (and the DLLs)
> >and I can run a test here. If they *have* fixe
Magnus Hagander wrote:
Can you check if your manually linked version works in non-US locales? If
you can't check, can you email me (offlist) with the binary (and the DLLs)
and I can run a test here. If they *have* fixed the issue so it works in
non-US locales, it's certainly worth expending som
On Tue, Sep 25, 2007 at 02:58:54AM -0400, Chuck McDevitt wrote:
> Actually, the more I look at it, I realize it was correct before
>
> We want to link against readline.lib and history.lib, but the ones in
> the GnuWin32 distribution are broken.
> The .lib files are made from the .def files, which
On Mon, Sep 24, 2007 at 01:33:33PM -0400, Chuck McDevitt wrote:
> Sorry, completion_matches hasn't existed in readline for a long time.
>
> You need to define:
>
> #define HAVE_RL_COMPLETION_APPEND_CHARACTER 1
> #define HAVE_RL_COMPLETION_MATCHES 1
> #define HAVE_RL_FILENAME_COMPLETION_FUNCTION 1
Chuck McDevitt wrote:
Maybe I need to do some research on readline... this seems more
complicated than I expected.
Does no one else use readline on Windows? Is the Gnuwin32 readline a
fraud? I just don't know.
readline has never worked well on Windows which is why we don't use it
with the of
ander'
> Cc: 'pgsql-hackers@postgresql.org'
> Subject: RE: [HACKERS] Suggestion for MSVC build
>
> Actually, the more I look at it, I realize it was correct before
>
> We want to link against readline.lib and history.lib, but the ones in
> the GnuWin32 distribution are b
gt; From: Chuck McDevitt
> Sent: Monday, September 24, 2007 2:17 PM
> To: Magnus Hagander
> Cc: pgsql-hackers@postgresql.org
> Subject: RE: [HACKERS] Suggestion for MSVC build
>
> The right lib files to link readline are the .a ones...
>
> Like this:
>
> if ($s
-
> From: Magnus Hagander [mailto:[EMAIL PROTECTED]
> Sent: Monday, September 24, 2007 1:30 AM
> To: Chuck McDevitt
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Suggestion for MSVC build
>
> What version readline are you using?
>
> I tried with the latest
ENAME_COMPLETION_FUNCTION 1
>
> Just like we do on Linux.
>
>
> > -Original Message-
> > From: Magnus Hagander [mailto:[EMAIL PROTECTED]
> > Sent: Monday, September 24, 2007 1:30 AM
> > To: Chuck McDevitt
> > Cc: pgsql-hackers@postgresql.o
rom: Magnus Hagander [mailto:[EMAIL PROTECTED]
> Sent: Monday, September 24, 2007 1:30 AM
> To: Chuck McDevitt
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Suggestion for MSVC build
>
> What version readline are you using?
>
> I tried with the latest download
What version readline are you using?
I tried with the latest download, and I get about 200 warnings like:
1>.\src\bin\psql\tab-complete.c(600) : warning C4013: 'completion_matches'
undef
ined; assuming extern returning int
1>.\src\bin\psql\tab-complete.c(600) : warning C4047: '=' : 'char **'
diffe
toronto programmer wrote:
Dear Postgres developers,
I have been working with Oracle for few years now in my work, and I
tried some free databases for a project that I'm developing for my own
use, I have tried H2,FireBird and postgres, and found the last to be
the most stable and feature-ric
On Apr 21, 2006, at 13:54, Bruce Momjian wrote:
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
Cool, thanks Bruce.
Best,
D
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Da
On Apr 3, 2006, at 14:37, Tom Lane wrote:
I would suggest handling this strictly as an addition to our
installation.sgml docs.
Finally got 'round to this. Patch attached. There are quite a few
environment variables in the list that Peter sent to me that I know
nothing about. These I've lis
Jim C. Nasby wrote:
On Fri, Mar 31, 2006 at 07:01:18PM -0500, Tom Lane wrote:
David Wheeler <[EMAIL PROTECTED]> writes:
Yes, but even the environment variables get me what I want. I
therefore respectfully submit the attached patch to document them in
the INSTALL file.
It seems rather pointl
Bruce Momjian wrote:
Andrew Dunstan wrote:
I don't know what unreasonable infrastructure you are referring to.
Building cvsup is a major pain, but installing and running it isn't, in
my experience. There's a package in Fedora Extras. Setting up cvsweb
against my cvsup repo is a fine idea
Andrew Dunstan wrote:
> I don't know what unreasonable infrastructure you are referring to.
> Building cvsup is a major pain, but installing and running it isn't, in
> my experience. There's a package in Fedora Extras. Setting up cvsweb
> against my cvsup repo is a fine idea - I wonder why I did
Robert Treat wrote:
The problem is that PostgreSQL is moving out of the realm of "hard-core
geeks only" and more into the mainstream. I'd bet a number of our users
have very little idea how autoconf and it's progeny work. It's probably
not unlikely that those folks would be able to figure out
1 - 100 of 244 matches
Mail list logo
