Robert Haas wrote:
> Vitali wrote:
>> When I select from the table, the timetz has the correct time
>> zone, the timestamptz has -6 as a time zone, which is my server
>> default.
>
> I'm not sure what you think the bug is, but timestamptz definitely
> doesn't store the time zone in which the v
Hi,
it seems pg_dump doesn't like -d option although it accepts --inserts. Same
with -D and --column-inserts.
I'm using pg_dump 8.4.1 on Ubuntu 9.10. I hope this is useful for you.
Thank you very much,
Vincent
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes t
The following bug has been logged online:
Bug reference: 5357
Logged by: Julien
Email address: julien.bar...@gmail.com
PostgreSQL version: 8.2.11
Operating system: Windows
Description:PGAdmin: SQL Query Editor does not (always) open files
Details:
Reproduction scena
On Tue, Mar 02, 2010 at 10:08:55AM +, Julien wrote:
> Description:PGAdmin: SQL Query Editor does not (always) open files
A better place for pgadmin problems is the pgadmin-support list:
http://www.pgadmin.org/support/list.php
--
Joshua Tolley / eggyknap
End Point Corporation
http://ww
On Tue, Mar 02, 2010 at 11:09:49AM +, Vincent Maury wrote:
> Hi,
>
> it seems pg_dump doesn't like -d option although it accepts --inserts. Same
> with -D and --column-inserts.
> I'm using pg_dump 8.4.1 on Ubuntu 9.10. I hope this is useful for you.
> Thank you very much,
>
> Vincent
pg_dum
Jonas Lund writes:
> What kind of functionality is tied to shared libs ?
Procedural languages, encoding conversions, walreceiver (in 9.0),
not to mention any sort of add-on such as contrib or pgfoundry modules.
> If building without shared libs isn't supported anymore then i think
> you should d
> Hmm ... out of curiosity, what exactly is your motivation for doing
> that? The reason we don't test this anymore is that so much of
> Postgres' functionality is bound up in loadable modules that a build
> without them seems of little use. It wouldn't even come close to
> passing the regression
Thank you for the response. I see your point. When I insert into field
timezonetz it does convert into correct timezone and inserts the converted
value. At the same time timestamp field just drops the timezone and inserts the
value.
However, I think that confusion comes when timetz works diffe
On Tue, 2010-03-02 at 08:32 -0700, Joshua Tolley wrote:
> On Tue, Mar 02, 2010 at 10:08:55AM +, Julien wrote:
> > Description:PGAdmin: SQL Query Editor does not (always) open files
>
> A better place for pgadmin problems is the pgadmin-support list:
> http://www.pgadmin.org/support/lis
The following bug has been logged online:
Bug reference: 5358
Logged by: Gurjeet Singh
Email address: singh.gurj...@gmail.com
PostgreSQL version: 8.4.2
Operating system: Windows Vista 64bit
Description:Throwing unexpected ERROR
Details:
I am using Postgres Plus Stan
Tom Lane wrote:
> Jeff Davis writes:
> > On Thu, 2010-02-25 at 23:15 -0500, Bruce Momjian wrote:
> >> Was this ever addressed?
>
> > It doesn't appear to be fixed, and I don't see it on the TODO, either.
> > Should we add it there?
>
> +1. It likely wouldn't be real hard to fix, but given the l
Vitali Malinouski wrote:
> Thank you for the response. I see your point. When I insert into
> field timezonetz it does convert into correct timezone and
> inserts the converted value. At the same time timestamp field
> just drops the timezone and inserts the value.
>
> However, I think that confus
"Gurjeet Singh" writes:
> select relname, pg_relation_size( 'public."' || relname || '"' )/1024
> from (select distinct relname
> from (select r.relname, c.attname, c.attnotnull, t.typname
> from pg_namespace as s, pg_class as r, pg_attribute as c,
> pg_type as t
>
Jonas Lund wrote:
>> Hmm ... out of curiosity, what exactly is your motivation for doing
>> that? The reason we don't test this anymore is that so much of
>> Postgres' functionality is bound up in loadable modules that a build
>> without them seems of little use. It wouldn't even come close to
>>
On Tue, Mar 2, 2010 at 7:51 PM, Tom Lane wrote:
> "Gurjeet Singh" writes:
> > select relname, pg_relation_size( 'public."' || relname || '"' )/1024
> > from (select distinct relname
> > from (select r.relname, c.attname, c.attnotnull, t.typname
> > from pg_namespace as s, pg_
15 matches
Mail list logo
