The following bug has been logged on the website:
Bug reference: 8266
Logged by: Denis de Bernardy
Email address: ddeberna...@yahoo.com
PostgreSQL version: 9.2.4
Operating system: OSX Lion
Description:
As identified in this StackOverflow thread:
http://stackoverflow
Andres Freund writes:
> There is no object 1832 in the dump since that was ommitted in favor of
> the constraint 1833 which internally creates the index. So what we need
> to do is to make the comment depend on the constraint instead.
> With the attached patch we get: [ the right thing ]
Applied
Andres Freund writes:
> On 2013-06-27 10:29:14 -0400, Tom Lane wrote:
>> Your proposed patch will only fix the problem for dumps created after
>> it ships. In the past, we've tried to deal with this type of issue by
>> having pg_restore fix up the dependencies when reading a dump, so that
>> it w
daniel.degasp...@r3-gis.com writes:
> CREATE TABLE t23456789012345678901234567890123456789012345678901
> (
> t1234_id serial,
> PRIMARY KEY (t1234_id)
> )
> WITH (
> OIDS=FALSE
> );
> This generated the sequence:
> CREATE SEQUENCE
> t2345678901234567890123456789012345678901234567890_t1234_i
Object names are limited to a length of NAMEDATALEN-1, which defaults to
63, and are documented to be truncated.
http://www.postgresql.org/docs/9.2/static/sql-syntax-lexical.html
The behaviour you are observing appears to conform to the documentation,
and seems reasonable, so I wouldn't think thi
The following bug has been logged on the website:
Bug reference: 8260
Logged by: Daniel Degasperi
Email address: daniel.degasp...@r3-gis.com
PostgreSQL version: 9.1.7
Operating system: Centos 6.4
Description:
I've created a table:
CREATE TABLE t234567890123456789012
On 2013-06-27 10:29:14 -0400, Tom Lane wrote:
> > ... So what we need
> > to do is to make the comment depend on the constraint instead.
> Your proposed patch will only fix the problem for dumps created after
> it ships. In the past, we've tried to deal with this type of issue by
> having pg_rest
Andres Freund writes:
> The problem is that pg_dump makes the comment depend on the index
> instead of the constraint:
Yeah, I figured that out yesterday, but hadn't gotten to writing a patch
yet.
> ... So what we need
> to do is to make the comment depend on the constraint instead.
Your propos
The following bug has been logged on the website:
Bug reference: 8259
Logged by: Varun
Email address: varunkark...@gmail.com
PostgreSQL version: 9.2.4
Operating system: Win 7
Description:
Hello,
NOt able to search composite type in search object
Ragrds
--
Sent
The following bug has been logged on the website:
Bug reference: 8258
Logged by: Varun
Email address: varunkark...@gmail.com
PostgreSQL version: 9.2.4
Operating system: Windows 7
Description:
hello,
object
Regards
--
Sent via pgsql-bugs mailing list (pgsql-bugs@p
On Wed, Jun 26, 2013 at 9:21 PM, wrote:
> The following bug has been logged on the website:
>
> Bug reference: 8255
> Logged by: gabriel
> Email address: gabriel...@santamonicace.com.br
> PostgreSQL version: 8.4.4
You are missing many minor releases. The latest version of 8.4 i
Hi Lloyd,
On 2013-06-26 23:43:00 +, lal...@fhcrc.org wrote:
> I have found the restore will fail when using pg_restore's -j option, with
> more than one core, on a dump that contains a COMMENT INDEX.
> Run this next section to add the table, index, and index comment to the
> test_db database.
12 matches
Mail list logo
