The following bug has been logged on the website:
Bug reference: 6726
Logged by: Andy Gumbrecht
Email address: andy.gumbre...@orprovision.com
PostgreSQL version: 9.1.4
Operating system: Windows 7 32 or 64 bit
Description:
Using:
"D:\pg\bin\pg_dump.exe" -F
On Sat, Jan 28, 2012 at 7:47 PM, Euler Taveira de Oliveira
wrote:
> On 28-01-2012 18:55, Andy Grimm wrote:
>> It's not uniform between the client and the server, though.
>>
> The server doesn't impose a hard limit for password length and AFAICS it
> should
On Sat, Jan 28, 2012 at 5:48 PM, Alvaro Herrera
wrote:
>
> Excerpts from Andy Grimm's message of sáb ene 28 14:32:24 -0300 2012:
>
>> Perhaps I should just submit the patch to pgsql-hackers ? I'm new to
>> the pgsql bug interaction process, so my apologies
On Sat, Jan 28, 2012 at 1:50 PM, Euler Taveira de Oliveira
wrote:
> On 28-01-2012 14:32, Andy Grimm wrote:
>> IMHO, there is a subtle difference here. If psql raised an error
>> message on passwords exceeding 100 characters, I would understand your
>> perspective, bu
e appropriate way to present the issue. I get Internal Server
Error messages when I attempt to subscribe to any of the pgsql mailing
lists, so this makes communication with the lists difficult.
--Andy
> --
> Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/
> Postg
ng with the standard "What do you mean you're not running autovacuum?"
--
Andy Lester => a...@petdance.com => www.petdance.com => AIM:petdance
el()). Is this a bug?
I can't imagine how it NOT be a bug to do something that gets rid of dead
tuples and then tell the user there are dead tuples when there are actually no
dead tuples.
xoa
--
Andy Lester => a...@petdance.com => www.petdance.com => AIM:petdance
--
Sen
The following bug has been logged online:
Bug reference: 5932
Logged by: Andy Lester
Email address: a...@petdance.com
PostgreSQL version: 9.0
Operating system: Linux
Description:CLUSTER doesn't update n_dead_tup
Details:
The CLUSTER command does not updat
On Jun 7, 2010, at 7:53 AM, Tom Lane wrote:
> Andy Balholm writes:
>> Is there a way to make values of "undefined" type pass through the
>> SELECT DISTINCT filter (getting checked for uniqueness) but remain
>> "undefined"
>
> No. What is your crit
Craig Ringer wrote:
> showing that your issue isn't actually with DISTINCT at all, but with Pg's
> unwillingness to *implicitly* cast a value of explict text type to another
> type.
Is there a way to make values of "undefined" type pass through the SELECT
DISTINCT filter (getting checked for un
had (and documented) a list for new features, it
might reduce some of the triage needed on -bugs.
Andy Balholm
(509) 276-2065
a...@balholm.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Apr 9, 2010, at 5:08 AM, Robert Haas wrote:
> Something is wrong with this
> mailing list.
In the week and a half that I've been subscribed to this mailing list, there
have been several times that I received a reply to a message without receiving
the original message. In most cases, I rece
On Apr 1, 2010, at 7:57 AM, Kevin Grittner wrote:
> I'm inclined to think it's better to have an explicit cast from
> money to numeric, as long as it is exact, and leave the division of
> money by money as float8. It does sort of beg the question of
> whether we should support a cast back in the o
> That's hardly an improvement if you're concerned about lack of
> exactness.
I know; I lose a couple of digits by using float8 instead of numeric, but it's
much simpler and faster, and if it returned numeric people would _think_ it was
exact.
And if we have a cast to numeric, people who want t
> Or I guess we could leave this as you've written it and add support
> for a cast from money to numeric.
I tried rewriting my function to use numeric, but I discovered that numeric
division is not exact. (Otherwise SELECT 1::numeric / 3::numeric would result
in an infinite loop.) So I went back
On Mar 31, 2010, at 11:01 AM, Kevin Grittner wrote:
> That was my first inclination, but the fact that two different
> people talked about using division by '1'::money as a way to convert
> money to another type has me nervous about using an approximate
> type. Any chance you could rework it usin
On Mar 31, 2010, at 7:07 AM, Kevin Grittner wrote:
> (I was going to mark the TODO as an easy one.)
I thought it would be pretty simple, too, so I decided to go ahead and write
and test it as an external module.
I think the function definition could be pasted directly into an appropriate
pl
rcent
one money value is of another. That is what I was wanting to use it for—finding
out what percentage of a customer's original balance has been paid off.
It would also provide a better way to convert money into numeric types than the
regular expression in the documentation. You c
The following bug has been logged online:
Bug reference: 5355
Logged by: Andy Lester
Email address: a...@petdance.com
PostgreSQL version: 8.3.6
Operating system: Linux
Description:locale incorrectly comma-separates "(null)"
Details:
In my .psqlrc
Using PostgreSQL 8.2.3, on linux (FC3):
test=> select lseg'((0,0),(1,0))' ?# lseg'((0,0),(1,0))';
-[ RECORD 1 ]
?column? | f
while
avail=> select lseg'((0,0),(1,0))' ?# lseg'((0,0),(1,1))';
-[ RECORD 1 ]
?column? | t
Looking over the geometric operations source it appears that the
intersect o
The following bug has been logged online:
Bug reference: 3978
Logged by: Andy Satori
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3
Operating system: Mac OS X
Description:plperl configure / build process behavior wrt Universal
Binaries
Details:
It appears
The following bug has been logged online:
Bug reference: 2629
Logged by: Andy McCurdy
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.4
Operating system: Windows XP
Description:libpq - Cannot deallocate prepared statement created
with PQprepare()
Details
always the same, is there some way we can view
the data being stored in the memory, or look at what data was stored in the
memory, and where, to see if the reference is valid?
Regards
Andy
“Tom
Lane writes:
>> We've seen reports of intermittent permission
failures on Wi
ill have a production server on which I can’t
run the database since I can’t debug the error. Any suggestions?
Thank
you for your assistance.
Andy
in the
database. Any help would be most appreciated.
Thanks
Andy
** LOG FILE SNIP **
2006-05-07 23:44:19 10.10.12.100(4018)LOG: 0: statement: EXECUTE
npgsqlportal1 [PREPARE: select * from
fn_Driver_Session_Updated($1::int8,$2::bool)]
2006-05-07 23:44:19 10.10.12.100(4018)LOCATION: ex
The following bug has been logged online:
Bug reference: 2419
Logged by: Andy Male
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1
Operating system: Windows 2003 Server (standard) SP1
Description:could not reattach to shared memory
Details:
FULL ERROR IN
The following bug has been logged online:
Bug reference: 2246
Logged by: Andy Klosterman
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.0
Operating system: Debian testing: Linux nc3 2.4.27-2-386 #1 Wed Nov 30
21:38:51 JST 2005 i686 GNU/Linux
Description:Bad
entry in the event viewer is :
Product: PostgreSQL 8.0-beta1 -- The installer has encountered an
unexpected error installing this package. This may indicate a problem
with this package. The error code is 2755. The arguments are: 1601,
C:\Documents and Settings\Andy T\My
Documents\download
Tom Lane wrote:
Andy Osborne <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
>
But with no way to reproduce it it's hard to pin blame.
Sad but true :-(
You didn't happen to make a physical copy of the news table before
dropping it, did you? It'd be interestin
Tom Lane wrote:
Andy Osborne <[EMAIL PROTECTED]> writes:
One of our databases crashed yesterday with a bug that looks
a lot like the non superuser vacuum issue that 7.2.3 was
intended to fix, although we do our vacuum with a user that
has usesuper=t in pg_user so I guess it's not
imilar problems with 7.2.3 ?. Any clues ?
Andy
--
Andy Osborne "Vertical B2B Communities"
Senior Internet Engineer
Sift Group100 Victoria Street, Bristol BS1 6HZ
tel:+44 117 915 9600 fax:+44 117 915 9630 http://www.sift.co
I am selecting rows from a table using "select *
from gla where glacode = $glresult[0]"
$glresult[0] comes from a previous query
result.
For the first three rows in the table I get the
error "Warning: Unable to jump to row 0 on PostgreSQL result index 4 in
/home/httpd/infocus/html/iris/ben_g
It would be useful to be able to search a list of known bugs for
the version of postgresql that you're running. Upgrading to the
latest version to see if it sorts out a problem isn't always a
sensible option..
Andy
- Original Message -
From: "Justin" <[EMAIL PROTE
Is there a repository on the web somewhere of all the bugs found, versions
they are found against and what theire status is?
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEm
Just discovered that column::date works fine but to_date(column, 'DD.MM.YY')
causes the problem. I was trying to write portable SQL, but never mind!
Andy
""Andy Marden"" <[EMAIL PROTECTED]> wrote in message
007301c1baad$b60d7b90$010a@marden1">
Do we have a workaround for 7.1.3? I don't really want to risk
an upgrade at this stage in the system
Cheers
Andy
- Original Message -
From: "Tom Lane" <[EMAIL PROTECTED]>
To: "Andy Marden" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: We
Is this a bug?
"Andy Marden" <[EMAIL PROTECTED]> wrote in message
news:a4u6fh$orp$[EMAIL PROTECTED]...
> Am loading date fields from text in one table to date in another. Format
of
> the text dates is 'DD.MM.YY', so that's the format mask I use. Dates for
&
37 matches
Mail list logo
