"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> Jonas Forsman wrote:
>
>> Try:
>> select * from table where lower(address) like '%Ã¥%'
>>
>> This select fails to find addresses including capital Ã… and similars in
>> LATIN1 (like Å, Ä, Ö).
Isn't à an upper-case letter? In which case lower
Pedro Gimeno wrote:
> Bruce Momjian wrote:
>
> > The fact is that 'public' is created from template1, so I suppose if
> > you remove it from there then new databases will not have it.
>
> That could cause installers for packages using PostgreSQL to fail if
> they create databases and expect "pu
Tom Lane wrote:
The hole in your argument is that this is not so. The purpose of a
backup is to get the *user's* objects into the same state they were
in. If we applied that reasoning to *system* objects then presumably
loading a dump from an 8.2 database into 8.3 would magically destroy
all th
Bruce Momjian wrote:
The fact is that 'public' is created from template1, so I suppose if
you remove it from there then new databases will not have it.
That could cause installers for packages using PostgreSQL to fail if
they create databases and expect "public" to exist.
Furthermore I mak
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> After looking at the callers I'm inclined to think that the only
>> safe way to implement this routine is to change its API to provide
>> both counts. Comments?
> +1
I've cleaned this up along with a fair amount of other infelicity
The following bug has been logged online:
Bug reference: 3739
Logged by: Jose
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.5
Operating system: Windows XP Pro SP2
Description:server process (PID XXX) exited with exit code
-1073741502
Details:
Process term
On Fri, Nov 09, 2007 at 07:59:07PM +, Dave Page wrote:
>
> As far as I know they haven't asked any of us for any personal info,
> money, bank details or anything like that. It appears to have been a
> legitimate query. That said, you should still be cautious and make sure
> you don't hand over
Linda O wrote:
> Dave- we received a similar solicitation at Artemis Woman
>
> Did these people turn out to be legitimate?
Linda,
As far as I know they haven't asked any of us for any personal info,
money, bank details or anything like that. It appears to have been a
legitimate query. That said,
Dave- we received a similar solicitation at Artemis Woman
Did these people turn out to be legitimate?
Thanks
Linda O
People; please *do not* respond to this. Someone from -core will handle it.
Thanks, Dave
--
Dave Page
PostgreSQL Core Team
--
View this message in context:
http://www.n
Magnus Hagander wrote:
>
> On Fri, 2007-11-09 at 10:27 -0300, Alvaro Herrera wrote:
> > Penty Wenngren wrote:
> >
> > > If you are confident that this is not a PostgreSQL bug, I'll accept that
> > > happily and move on to do some more testing on my end.
> >
> > I don't think it has been shown th
Ben Leslie wrote:
> The specific problem is that the following is malformed; the xsd:restriction
> tag is never closed.
>
>
>
>
>
Exact. Per 9.11 (6, b, iv) or 9.15 (8, m, vi), it's a simple element.
The attached patch should fix it.
I'm attaching another small patch to strip some space
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > I am wondering if the newline being included in the token could be
> > causing a problem.
>
> Nope. I traced through it and the problem is that char2wchar() is
> completely brain-dead: at some places it thinks that "len" is the
> le
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I am wondering if the newline being included in the token could be
> causing a problem.
Nope. I traced through it and the problem is that char2wchar() is
completely brain-dead: at some places it thinks that "len" is the
length of the output wchar array
Jonas Forsman wrote:
it is possibly a locale-error. may I ask:
1. How do I check the locale?
Within psql:
show lc_ctype; (and other lc_* variables as well)
show server_encoding;
show client_encoding;
2. Can I change this on already running db:s ?
Unfortunately you can't. You'll have to re-
Pedro Gimeno wrote:
>
> Since I received no feedback, I think this may have been dismissed as
> "not a bug". Here are further arguments on why I believe it's a bug:
>
> (The following assumes that schema "public" was dropped from the target
> database prior to the dump.)
>
> -Creating a dump
"Chris Vickery" <[EMAIL PROTECTED]> writes:
> Description:psql crashes on exit.
We've seen this before --- there's a bug in the Apple-supplied libedit:
http://archives.postgresql.org/pgsql-hackers/2006-12/msg01222.php
My suggestion would be to rebuild using libreadline, which is a lot mor
Pedro Gimeno <[EMAIL PROTECTED]> writes:
> ... it's usually assumed that the purpose of a backup
> is to be able to get things to the exact same state as they were when
> it was created.
The hole in your argument is that this is not so. The purpose of a
backup is to get the *user's* objects i
Have you checked your PostgreSQL configuration? Have you checked
your firewall? Did you read the last line of the text you posted,
where it says "Please check this thoroughly before reporting a bug to
the PostgreSQL community" ?
I give kudos to the support team for being very tolerant and
Jonas Forsman wrote:
The following bug has been logged online:
Bug reference: 3737
Logged by: Jonas Forsman
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.10
Operating system: Ubuntu 6.06 LTS
Description:lower/upper fails to match extended chars in LATIN1
The following bug has been logged online:
Bug reference: 3738
Logged by: Chris Vickery
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.5
Operating system: OS X 10.4
Description:psql crashes on exit.
Details:
senate=# \q
psql(4484) malloc: *** error for obje
The following bug has been logged online:
Bug reference: 3737
Logged by: Jonas Forsman
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.10
Operating system: Ubuntu 6.06 LTS
Description:lower/upper fails to match extended chars in LATIN1
Details:
Try:
select
The following bug has been logged online:
Bug reference: 3736
Logged by: Derek
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.10
Operating system: Windows XP Professional
Description:server cannot listen
Details:
when i try to connect to the postgreSQL dat
Am Freitag, 9. November 2007 schrieb Ben Leslie:
> # select xmlpi(name "xml-stylesheet");
> ERROR: invalid XML processing instruction
> DETAIL: XML processing instruction target name cannot start with "xml".
Apparently I read the SQL spec a bit to strictly here. I've installed a fix
into CVS.
The following bug has been logged online:
Bug reference: 3734
Logged by: Ben Leslie
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3 beta2
Operating system: Mac OS X
Description:Invalid XML schema output.
Details:
database_to_xml_and_xmlschema creates an inv
George Woodman wrote:
> I have 2 records with the following details:
> george,George,george,developer
> 1234567890,Temp,0,developer
> When I try to retrieve this record with the following statement from a
> ASP.Net (VB) app I get no rows returned.
> Select * from user_control where uci = 'george'
Since I received no feedback, I think this may have been dismissed as
"not a bug". Here are further arguments on why I believe it's a bug:
(The following assumes that schema "public" was dropped from the target
database prior to the dump.)
-Creating a dump (following section 23.1 of the 8
Tom Lane wrote:
> Penty Wenngren <[EMAIL PROTECTED]> writes:
> > I used iconv to convert svenska.aff and svenska.datalist (from
> > iswedish-1.2.1) to UTF-8. The converted files can be found at:
> > http://www.lederhosen.org/swedish.affix
> > http://www.lederhosen.org/swedish.dict
>
> I think the
On Fri, 2007-11-09 at 10:27 -0300, Alvaro Herrera wrote:
> Penty Wenngren wrote:
>
> > If you are confident that this is not a PostgreSQL bug, I'll accept that
> > happily and move on to do some more testing on my end.
>
> I don't think it has been shown that this is not our bug. I reproduced
>
Penty Wenngren wrote:
> If you are confident that this is not a PostgreSQL bug, I'll accept that
> happily and move on to do some more testing on my end.
I don't think it has been shown that this is not our bug. I reproduced
your problem here on an UTF8 environment and it does fail for me.
On th
The following bug has been logged online:
Bug reference: 3735
Logged by: Ben Leslie
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3 beta 2
Operating system: Mac OS X
Description:Can't create xml-stylesheet processing instruction
Details:
# select xmlpi(name
George Woodman wrote:
I created a table with the following specs.
CREATE TABLE user_control
(
uci character varying(10) NOT NULL,
ucname character varying(20),
ucpwd character varying(10),
ucrole character varying(20),
CONSTRAINT user_control_pkey PRIMARY KEY (uci)
)
WITH (OIDS=FALSE);
heasley wrote:
Thu, Nov 08, 2007 at 11:04:01AM +0100, Zdenek Kotala:
heasley napsal(a):
The configure is via NetBSD's pkgsrc system.
./configure --sysconfdir=/usr/pkg/etc/postgresql --datadir=/usr/pkg/share/po
stgresql --with-docdir=/usr/pkg/share/doc/postgresql --with-template=solaris --w
Em Qui, 2007-11-08 às 12:29 -0500, Tom Lane escreveu:
> "Daniel Cristian Cruz" <[EMAIL PROTECTED]> writes:
> > A few moments ago I got the following message, but didn't found any
> > reference on the internet (including lists).
>
> > Nov 8 13:50:56 SERVER postgres[18874]: [5-1] user=XXX,db=XXXPAN
The following bug has been logged online:
Bug reference: 3732
Logged by: George Woodman
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.5
Operating system: Windows 2000
Description:Select returns 0 rows for varchar field
Details:
I created a table with the
Sajan S wrote:
We are working on MapServer with postgresql-8.1.8 on
fedora core 4. The geometry data type is not available in the linux version
of PostgreSQL. In postgresql 8.0.0beta5(windows version ) the geometry data
type is available, which we use on our Windows machine.
On Thu, Nov 08, 2007 at 08:45:32PM -0500, Tom Lane wrote:
> Penty Wenngren <[EMAIL PROTECTED]> writes:
> > On Thu, Nov 08, 2007 at 05:21:17PM -0500, Tom Lane wrote:
> >> I suspect you are working in a locale that doesn't think à is a
> >> letter --- check lc_ctype.
>
> > It doesn't seem to make a
Sir/Madam,
We are working on MapServer with postgresql-8.1.8 on
fedora core 4. The geometry data type is not available in the linux version
of PostgreSQL. In postgresql 8.0.0beta5(windows version ) the geometry data
type is available, which we use on our Windows machine. But it
On Thu, Nov 08, 2007 at 05:21:17PM -0500, Tom Lane wrote:
> Penty Wenngren <[EMAIL PROTECTED]> writes:
> > I used iconv to convert svenska.aff and svenska.datalist (from
> > iswedish-1.2.1) to UTF-8. The converted files can be found at:
> > http://www.lederhosen.org/swedish.affix
> > http://www.led
38 matches
Mail list logo
