Andy Lester wrote:
>
> On Sep 5, 2011, at 3:19 PM, Bruce Momjian wrote:
>
> >
> > This is an interesting bug report from March that got no replies. In my
> > testing, not only does CLUSTER not update the n_dead_tup statistics, but
> > neither does VACUUM FULL, which internally uses the CLUSTER
On Sep 6, 2011, at 9:04 AM, Bruce Momjian wrote:
> Well, if you TRUNCATE I don't think it updates the statistics either. I
> think we assume the autovacuum system will analyse the new table soon.
When I brought this up in IRC, I recall that that sentiment was expressed,
along with the standar
Andy Lester wrote:
>
> On Sep 6, 2011, at 9:04 AM, Bruce Momjian wrote:
>
> > Well, if you TRUNCATE I don't think it updates the statistics either. I
> > think we assume the autovacuum system will analyse the new table soon.
>
>
> When I brought this up in IRC, I recall that that sentiment was
On Mon, Sep 05, 2011 at 02:27:23PM -0400, Tom Lane wrote:
> It's not just the port, it's all the connection parameters ---
> do_connect relies on the PGconn object to remember those, and in this
> case there no longer is a PGconn object.
>
> We could have psql keep that information separately, but
hubert depesz lubaczewski writes:
> On Mon, Sep 05, 2011 at 02:27:23PM -0400, Tom Lane wrote:
>> It's not just the port, it's all the connection parameters ---
>> do_connect relies on the PGconn object to remember those, and in this
>> case there no longer is a PGconn object.
>>
>> We could have
On Tue, Sep 06, 2011 at 11:35:43AM -0400, Tom Lane wrote:
> hubert depesz lubaczewski writes:
> > On Mon, Sep 05, 2011 at 02:27:23PM -0400, Tom Lane wrote:
> >> It's not just the port, it's all the connection parameters ---
> >> do_connect relies on the PGconn object to remember those, and in this
Tom Lane wrote:
> hubert depesz lubaczewski writes:
> > On Mon, Sep 05, 2011 at 02:27:23PM -0400, Tom Lane wrote:
> >> It's not just the port, it's all the connection parameters ---
> >> do_connect relies on the PGconn object to remember those, and in this
> >> case there no longer is a PGconn obj
The following bug has been logged online:
Bug reference: 6199
Logged by: Hadmut
Email address: had...@danisch.de
PostgreSQL version: 9.1 rc1
Operating system: Ubuntu Oneiric
Description:Can't install datatype hstore
Details:
Hi,
I'd like to run a database applicati
"Hadmut" writes:
> I'd like to run a database application which requires datatype hstore.
> But when trying something like
> psql -f /usr/share/postgresql/9.1/extension/hstore--1.0.sql
That is not how you install extensions anymore. Use CREATE EXTENSION.
regards, tom
Josh Berkus wrote:
> I have another example of this issue with WIN1252. This line in a copy
> file:
>
> 659446 828 1 /6???\bH@^W^Za$H???\b???@\\/No
> valid or unique HTTP objects found in XML response.
>
> Into this table:
>
> Table "public.ep_tests"
> Column | Type
Added to TODO:
Improve PERFORM handling of WITH queries or document limitation
---
depst...@alliedtesting.com wrote:
> Update: It has been suggested to wrap perform around a select like this:
>
> do
> $$begin
> per
Grzegorz Szpetkowski wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5957
> Logged by: Grzegorz Szpetkowski
> Email address: gszpetkow...@gmail.com
> PostgreSQL version: 9.0.3
> Operating system: Ubuntu 10.10
> Description:createdb with descrip
Yeah, Definitely it's not *expected* behavior so documentation is the good
starting point unless we fix the code soon. I don't agree with Tom's comment
on we should find out the reason for crash instead. In most of the cases,
reason for the crash is because someone restarted database and user tryin
depst...@alliedtesting.com wrote:
> Update: It has been suggested to wrap perform around a select like this:
>
> do
> $$begin
> perform(
> with A as (select 1 as foo)
> select foo from A
> );
> end$$;
>
> This won't work if select returns more than one statement:
>
> do
> $$begin
> perform(
> wi
On 06.09.2011 18:26, Tom Lane wrote:
> Use CREATE EXTENSION.
Yup, that worked. Thanks! :-)
regards
Hadmut
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> It already is documented. See
> >> http://developer.postgresql.org/pgdocs/postgres/datatype-datetime.html#DATATYPE-TIMEZONES
> >> specifically the point that POSIX zone names have the opposite sign
> >> convention from ISO-8601.
> >
16 matches
Mail list logo
