Thanks Tom and Kevin
for your detailed explanation. Even if I know now there is no chance of
changing it I'd like you to consider following fact:
when writing a character constant elsewhere
then at first it is interpreted as character constant - right?
then it is casted to the desired type
e.g
On Thu, Nov 26, 2009 at 5:41 AM, Walter Willmertinger wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5215
> Logged by: Walter Willmertinger
> Email address: will...@gmail.com
> PostgreSQL version: 8.4.1
> Operating system: Windows XP Prof.
> Descriptio
Michał Pasternak wrote:
1 month / 1 day equals 30.
or 31 or 28 or 29...
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
1 month / 1 day equals 30.
-Original Message-
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Sent: Thursday, December 03, 2009 12:46 AM
To: Michal Pasternak
Cc: pgsql-bugs@postgresql.org
Subject: Re: [BUGS] BUG #5227: please add a divide operator for intervals
"Michal Pasternak" writes:
>
"Michal Pasternak" writes:
> Please add a divide operator for INTERVAL type, if possible.
Given that intervals have multiple subfields, it's far from obvious
what division should mean. What is '1 month' / '1 day'?
> db=# SELECT EXTRACT(EPOCH FROM '15 seconds'::INTERVAL) / EXTRACT(EPOCH FROM
> '
"Kevin Grittner" writes:
> Quoting from section 5.3 of "WG3:HBA-003 H2-2003-305 August, 2003
> (ISO-ANSI Working Draft) Foundation (SQL/Foundation)":
> | 13) The declared type of a is
> | fixed-length character string.
> Treating an otherwise unadorned set of characters between two
> apostrop
The following bug has been logged online:
Bug reference: 5227
Logged by: Michal Pasternak
Email address: michal@gmail.com
PostgreSQL version: 8.4
Operating system: doesn't matter
Description:please add a divide operator for intervals
Details:
Please add a divide
Heikki Linnakangas writes:
> The logical next step would be to get rid of the interXact concept
> altogether and always associate temporary files with the current
> resource owner; the caller should switch to a sufficiently long-lived
> one before calling.
That would mean having a session-lifespa
Heikki Linnakangas wrote:
> Tom Lane wrote:
>> So as far as I can tell at the moment, temp files really are the only
>> problem, and making them be managed by resource owners instead of a
>> subxact-based release policy should fix that.
>
> Ok, good.
>
>> I can go work on that, unless you wante
Heikki Linnakangas writes:
> Tom Lane wrote:
>> I can go work on that, unless you wanted to?
> I started hacking on that when I posted, so I can finish it.
Sounds good. I added a bit to the ROLLBACK TO reference page to remind
us what we think the behavior is supposed to be for cursor rollback.
Tom Lane wrote:
> So as far as I can tell at the moment, temp files really are the only
> problem, and making them be managed by resource owners instead of a
> subxact-based release policy should fix that.
Ok, good.
> I can go work on that, unless you wanted to?
I started hacking on that when
I wrote:
> Heikki Linnakangas writes:
>> Hmm, I think we should track temporary files using resource owners.
> That would probably be a workable solution if temp files are the only
> problem. What I'm afraid of is that this type of problem exists
> *everywhere* that we track the need for cleanup
Tom Lane wrote:
> Heikki Linnakangas writes:
> > Tom Lane wrote:
> >> Not sure what to do. The only fix that seems bulletproof at the moment
> >> is to declare that any cursor that's been touched at all in a
> >> subtransaction is marked "broken" if the subtransaction rolls back.
> >> That might
Heikki Linnakangas writes:
> Tom Lane wrote:
>> Not sure what to do. The only fix that seems bulletproof at the moment
>> is to declare that any cursor that's been touched at all in a
>> subtransaction is marked "broken" if the subtransaction rolls back.
>> That might be too great a loss of funct
Craig Ringer wrote:
> On 3/12/2009 12:35 AM, Tom Lane wrote:
>> You really ought to cast the 'I' to some specific type.
>
> It's usually neatest to do this by just explicitly identifying
> the intended type in the first place, eg:
>
>
> SELECT firmnr,
> werknr,
>
On Wed, Dec 2, 2009 at 11:42 AM, Craig Ringer
wrote:
> On 2/12/2009 10:35 PM, aftab wrote:
>>
>> The following bug has been logged online:
>>
>> Bug reference: 5226
>> Logged by: aftab
>> Email address: akha...@hotmail.co.uk
>> PostgreSQL version: 8.3.8
>> Operating system: Ce
On 3/12/2009 12:35 AM, Tom Lane wrote:
"Kurt wagner" writes:
During migration from Informix to Postgres I came across following issue:
create temp table temp1 as
SELECT firmnr,
werknr,
'I' as invper,
invnum
from ;
You really ought to cast the
On 2/12/2009 10:35 PM, aftab wrote:
The following bug has been logged online:
Bug reference: 5226
Logged by: aftab
Email address: akha...@hotmail.co.uk
PostgreSQL version: 8.3.8
Operating system: Centos 5
Description:Limit operator slows down
Details:
S1="SELECT *
"Kurt wagner" writes:
> During migration from Informix to Postgres I came across following issue:
> create temp table temp1 as
>SELECT firmnr,
>werknr,
>'I' as invper,
>invnum
>from ;
You really ought to cast the 'I' to some specific type. The ab
Please consider this issue as resolved. Reinstallation seems to have fixed
it.
The service is running, as noted before and I am able to connect and use the
database. My syntax was wrong in the previous email.
Thanks again.
Sriram
On Wed, Dec 2, 2009 at 7:51 AM, Sriram Gopalan wrote:
> 1. After
1. After I reinstalled the latest version of postgresql, I do see a service
called postgresql-8.4.
2. It is started automatically.
Please note, however, that I am still not able to connect to the database.
For example, trying to use psql gives me the following error:
psql: could not connect to se
The following bug has been logged online:
Bug reference: 5226
Logged by: aftab
Email address: akha...@hotmail.co.uk
PostgreSQL version: 8.3.8
Operating system: Centos 5
Description:Limit operator slows down
Details:
S1="SELECT *
FROM position WHERE
position.POSITIO
The following bug has been logged online:
Bug reference: 5225
Logged by: Kurt wagner
Email address: kurt.wagnerext...@leoni.com
PostgreSQL version: 8.41
Operating system: HP-UX
Description:create table: cast necessary for constant??
Details:
During migration from In
On 2/12/2009 11:57 PM, Sriram Gopalan wrote:
Please consider this issue as resolved. Reinstallation seems to have
fixed it.
The service is running, as noted before and I am able to connect and use
the database. My syntax was wrong in the previous email.
Ah, OK. Please disregard my previous mai
On 2/12/2009 11:51 PM, Sriram Gopalan wrote:
1. After I reinstalled the latest version of postgresql, I do see a
service called postgresql-8.4.
2. It is started automatically.
Yes, but is it *running* ? The service manager shows the current status
(running or stopped) separately to the startup
On 2/12/2009 12:57 PM, Sriram Gopalan wrote:
The following bug has been logged online:
Bug reference: 5224
Logged by: Sriram Gopalan
Email address: sriramgopa...@gmail.com
PostgreSQL version: 8.4.1
Operating system: Windows 7
Description:After upgrading from vista t
On Wed, Dec 2, 2009 at 1:12 AM, Craig Ringer
wrote:
> On 2/12/2009 2:25 AM, Nicolas urtizberea wrote:
>>
>> The following bug has been logged online:
>>
>> Bug reference: 5222
>> Logged by: Nicolas urtizberea
>> Email address: nurtizbe...@gmail.com
>> PostgreSQL version: 8.3.1-1
27 matches
Mail list logo
