On Mon, Aug 27, 2012 at 1:34 PM, Tom Lane wrote:
> Robert Haas writes:
> > Maybe, but in that case shouldn't referencing a system column chuck an
> error?
>
> Yeah, possibly. I think none of them are populated with anything useful
> during INSERT checks (though OID might be an exception?). Les
On Wed, Mar 14, 2012 at 07:19:14PM +0100, Rikard Pavelic wrote:
> On 13.3.2012. 20:49, Merlin Moncure wrote:
> > I personally think it's an oversight. This was just discussed a
> > couple of days ago here:
> > http://postgresql.1045698.n5.nabble.com/Altering-a-table-with-a-rowtype-column-td5544844
Bruce Momjian writes:
> Tom, can you comment on this patch because you commented on the previous
> version? Thanks.
Doesn't that provoke a pile of compiler warnings about local variables
potentially being altered during longjmp? It sure looks pretty unsafe
from here. It also fails to print any
Robert Haas writes:
> Maybe, but in that case shouldn't referencing a system column chuck an error?
Yeah, possibly. I think none of them are populated with anything useful
during INSERT checks (though OID might be an exception?). Less sure
about the state during UPDATE checks, though.
On Fri, Aug 24, 2012 at 10:38 AM, Tom Lane wrote:
> Chris Travers writes:
>> Table inheritance would be easier if there was a way to declare a
>> constraint such that it prevents insert for some rows on the parent
>> but not for a child and/or vice versa.
>
> FWIW, 9.2 adds support for constraint
i...@fuelforce.com writes:
> Attempting to restore a db using pg_restore to a new database server using
> the --create and --dbname flags fails silently if the db owner username does
> not exist in the new db or the -O flag is not used.
> Command used:
> pg_restore --create --verbose --dbname=tests
The following bug has been logged on the website:
Bug reference: 7507
Logged by: Ian Nobile
Email address: i...@fuelforce.com
PostgreSQL version: 9.1.4
Operating system: Mac OS X Version 10.8
Description:
Attempting to restore a db using pg_restore to a new database s
On Sat, Jan 28, 2012 at 01:47:04PM -0500, Tom Lane wrote:
> Euler Taveira de Oliveira writes:
> > I don't see it as a bug but a limitation. Why do you need such a long
> > password?
>
> Yeah, I think the reason we're not too consistent about this is that
> nobody ever imagined that limits of 100
Bruce Momjian writes:
> Did we want this patch applied? Not enough demand?
It seems a bit overengineered at this point. I realize Andy wasn't the
one pushing to support arbitrary-length passwords originally, but I
can't see adding this much code for that. I don't even see the value
of allowin
Excerpts from Bruce Momjian's message of lun ago 27 12:12:25 -0400 2012:
>
> Did we want this patch applied? Not enough demand?
I think it should be in the next commitfest for discussion. I don't see
any reason to reject it. I think it needs some fixes, though, so a
formal review process is c
Did we want this patch applied? Not enough demand?
---
On Wed, Feb 15, 2012 at 12:09:12AM -0500, Andy Grimm wrote:
> On Sat, Jan 28, 2012 at 7:47 PM, Euler Taveira de Oliveira
> wrote:
> > On 28-01-2012 18:55, Andy Grimm
Is this a TODO?
---
On Thu, Jan 19, 2012 at 10:39:42AM -0500, Tom Lane wrote:
> Alvaro Herrera writes:
> > Excerpts from Heikki Linnakangas's message of jue ene 19 07:25:36 -0300
> > 2012:
> >> Frankly that's such a rare c
On Tue, Jan 17, 2012 at 04:46:50PM -0500, David Schnur wrote:
> I finally had time to test this further on a variety of systems, and was
> unable
> to reproduce on any non-Windows platform. The dump even works fine on Windows
> XP; just not Windows 7.
>
> This prompted me to do a little more res
My English is very poor, below Google Translate:
"It is possible but ... Did you see any ERROR message (s) related to
statistics
collector before those ones? "
---
Found no other error messages related to this. Disk hardware is also normal.
According to my observation, is the process of
14 matches
Mail list logo
