"terry" <94487...@qq.com> writes:
> TEST=# CREATE TABLE B (C NUMERIC(8,3));
> CREATE TABLE
> TEST=# INSERT INTO B VALUES (12345.678);
> INSERT 0 1
> TEST=# SELECT * FROM B;
> c
> ---
> 12345.678
> (1 row)
> TEST=# ALTER TABLE B ALTER COLUMN C TYPE NUMERIC(4,0);
> ERROR: numeric
The following bug has been logged online:
Bug reference: 4973
Logged by: terry
Email address: 94487...@qq.com
PostgreSQL version: 8.3.3
Operating system: linux
Description:number precision or scale lost when altering table
column
Details:
Welcome to psql 8.3.3, the
Robert Haas escribió:
> On Fri, Aug 7, 2009 at 12:31 AM, Rob Wultsh wrote:
> > http://www.postgresql.org/docs/8.4/static/geqo-biblio.html links to "The
> > Hitch-Hiker's Guide to Evolutionary Computation"
> > (http://www.cs.bham.ac.uk/Mirrors/ftp.de.uu.net/EC/clife/www/location.htm)
> > which as o
On Mon, Aug 10, 2009 at 11:10 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Jul 17, 2009 at 10:21 AM, Tom Lane wrote:
>>> Actually, now that I think about it, the planner already has
>>> datatype-specific knowledge about boolean equality (see
>>> simplify_boolean_equality). It would take j
On Mon, Aug 10, 2009 at 20:44, Tom Lane wrote:
> Magnus Hagander writes:
>> If I just move those two lines into the #ifndef WIN32 block just
>> around it, it compiles and doesn't crash on running-with-no-arguments.
>> I haven't tried to actually use it though - can someone confirm if
>> this will
Magnus Hagander writes:
> If I just move those two lines into the #ifndef WIN32 block just
> around it, it compiles and doesn't crash on running-with-no-arguments.
> I haven't tried to actually use it though - can someone confirm if
> this will actually make pg_standby not work properly?
It would
Jeff Janes wrote:
>
> The following bug has been logged online:
>
> Bug reference: 4965
> Logged by: Jeff Janes
> Email address: jeff.ja...@gmail.com
> PostgreSQL version: 8.4.0
> Operating system: Linux
> Description:missing tests in tools/fsync/test_fsync.c
> Detail
On Mon, Aug 10, 2009 at 16:10, wader2 wrote:
> Bruce Momjian wrote:
>>
>> I can't reproduce a crash here on BSD:
>>
>> $ pg_standby
>> pg_standby: not enough command-line arguments
>>
>> Can you show us the command and the crash text?
>
> I guess this occurs on only windows (Japanese
Hi.
Yes, I also reproduce it. It is very strange..
==
Windows-XP Home Edition Version2002 Service Pack3(Japanese)
CPU N270 @ 1.60Ghz 1GB RAM
==
C:\Program Files\PostgreSQL\8.4\bin>pg_standby.exe --help
pg_standby allows PostgreSQL warm standby servers to be configured.
Usage:
C:\Program
Richard Neill writes:
> (b) Nowhere on the page is there a full example for getting
> seconds+microseconds since the epoch
Yeah, we could change that example to include a fractional part in the
timestamp to make this clearer.
> What I think I meant was dividing a differential timestamp b
Robert Haas writes:
> On Fri, Jul 17, 2009 at 10:21 AM, Tom Lane wrote:
>> Actually, now that I think about it, the planner already has
>> datatype-specific knowledge about boolean equality (see
>> simplify_boolean_equality). It would take just a few more lines of code
>> there to recognize "x <>
Bruce Momjian wrote:
I can't reproduce a crash here on BSD:
$ pg_standby
pg_standby: not enough command-line arguments
Can you show us the command and the crash text?
I guess this occurs on only windows (Japanese envionment?).
C:\Program Files\PostgreSQL\8.4\bin>pg_standby.ex
On Mon, Aug 10, 2009 at 8:52 AM, Richard Neill wrote:
> What I think I meant was dividing a differential timestamp by an interval.
> In this case, both should be unambiguously expressed in seconds, and the
> result will be dimensionless.
And what will you get when you divide 1 month by 1 day?
...
On Fri, Jul 17, 2009 at 10:21 AM, Tom Lane wrote:
> Peter Eisentraut writes:
>> ... But again, this is data type specific knowledge.
>
> Actually, now that I think about it, the planner already has
> datatype-specific knowledge about boolean equality (see
> simplify_boolean_equality). It would ta
Robert Haas wrote:
On Fri, Jul 31, 2009 at 11:00 AM, wrote:
The following bug has been logged online:
Bug reference: 4959
Logged by:
Email address: wad...@jcom.home.ne.jp
PostgreSQL version: 8.4.0
Operating system: Windows
Description:unable to install/start service
Details
Dear Peter and Tom,
Thanks for your help. Sorry for posting an incorrect bug report. I hope
there are still a few useful parts...
Tom Lane wrote:
"Richard Neill" writes:
* Convert a timestamp into a number of seconds since
the epoch. This can be done in an ugly way using EXTRACT epoch FROM
utsav wrote:
Dear All,
I am using postgres 7.3 version on RHEL 4.0.
7.3 is not a supported release any more you really need to look into
getting something non-prehistoric - and what version of 7.3 exactly?
My database has been restored.
"restored" - how exactly? From a file system backup
Dear All,
I am using postgres 7.3 version on RHEL 4.0.
My database has been restored.
All tables all working fine i.e select , update but on a particular table its
showing error
"ERROR: XLogFlush: request AF/5703EDC8 is not satisfied --- flushed only to
AF/50F15ABC "
I have searched other
On Monday 10 August 2009, Richard Neill wrote:
> * So, for example, to check whether two timestamps (ts1 and ts2) are less
> than 2.5 seconds apart, (returning boolean), I'd like to be able to do at
> least one of:
>
> abs(time(ts1 - ts2)) < 2.5
> #A "time" function converts timestamp to
> #s
On Monday 10 August 2009 03:41:06 Richard Neill wrote:
> * Division of a timestamp by an interval should result in something
> dimensionless.
What would be the semantics of this? What's today divided by 2 hours?
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to
Jan-Ivar Mellingen skrev:
> One of our customers discovered that by replacing <>TRUE with =FALSE in
> a query of a table containing 750.000 records reduced the query time
> from about 12 seconds to about 60 milliseconds!
>
> The problematic query looks like this:
> SELECT * FROM AlarmLogg WHERE L
21 matches
Mail list logo
