but the backend seems to
return not an Int/Long but the type name instead.
It's interesting to see that other code is getting the same problem.
Peter
ive up on Cygwin and go back to what I did last time? Is there
a document or web page that describes a successful installation step by
step?
Peter
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
perform a few hours development each month. What I need is a bullet
proof way of installing PostgreSQL on NT.
Peter
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
: incomplete startup packet
Peter
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Am Freitag, 11. Juli 2008 schrieb Fred Perniss:
> In Postgres the switch add_mising_from=on the SQL-Command
>
> DELETE FROM t2
> WHERE (t2.t2_t1_id=t1.t1_id)
> AND t1.t1_inhalt=5
> ;
>
> works (with message in Log).
>
> If the switch add_missing_from=off following Error-Message will be promted:
>
>
Am Tuesday, 22. July 2008 schrieb valgog:
> Why Postgres allows creating UNICODE database with the locale, that
> can possibly corrupt my data?
It doesn't allow it, as of 8.3. In 8.2 it does, but we have fixed that, for
the reasons that are becoming obvious to you now.
Perhaps part of the probl
Am Thursday, 7. August 2008 schrieb Tom Lane:
> I rather wonder whether -L has any reason to live at all. initdb's
> default is to locate PGSHAREDIR relative to where it finds the backend
> executable, which is consistent with what the backend itself is going
> to do. Is there any scenario where
Am Saturday, 9. August 2008 schrieb Richard Evans:
> I've made a couple of patches, for 8.3.3 and 8.2.9, which enable cross
> compilation for windows (mingw32) from a unix platform.
This looks good, with a couple of tweaks. I don't think we are going to be
making these kinds of changes in the 8.
Am Friday, 15. August 2008 schrieb Tariq Aziz:
> I have installed PostGRESql 8.3 and try in to retrieve data in xml
> format for which I need to use function "xmlAgg". but that's not
> supported in the instance I have configured. Kindly guide me If there is
> some service pack or patch required to
Am Friday, 15. August 2008 schrieb Grigory Zinin:
> We can create SERIAL field. But INTEGER type will be really set. It's well
> known that INTEGER field doesn't match values more than 4 bytes. But
> related SEQUENCE object has a 8 byte value.
> It looks strange for me that 4 bytes of these 8 byte
Dan Kaminsky wrote:
> >> 1) No roots (but still works for some unknown reason)
> >> 2) Explicitly configured corporate roots
> >> 3) Explicitly configured corporate roots, AND global roots
> >> 4) Global roots (but still works for some unknown reason)
> So, if you do nothing special, it's #1? Sou
[EMAIL PROTECTED] wrote:
> Is this possible?
That is a question, not a bug.
But yes, it is possible.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Richard Evans wrote:
> I'm not sure why the makefiles need the current directory. pwd -W is
> specific to mingw, I think it gives the directory in windows format. It
> has to be changed for cross compilation otherwise you get errors.
What does $(CURDIR) resolve to on mingw? Try the following mak
[EMAIL PROTECTED] wrote:
> 1. Install Perl v5.10
> 2. Install PG
> 3. PG does not see that machine has Perl
> 4. Remove Perl and PG
> 5. Instll Perl v5.8
> 6. Install PG
> 7. PG work fine
> Problem is that PG does not recognize Perl v5.10 =(
Please provide the actual commands and the actual output
erating words are "typically" and "around". You can put in smaller and
larger values, but then the precision is going to degrade, as you can observe
here:
peter=# select '1E-305'::float8;
float8
1e-305
(1 row)
peter=# select '1E-310'::float8;
On Monday 25 August 2008 13:29:14 [EMAIL PROTECTED] wrote:
> ERROR: encoding LATIN2 does not match server's locale en_AU.UTF-8
> DETAIL: The server's LC_CTYPE setting requires encoding UTF8.
In 8.3, it no longer works to create databases of different or incompatible
encodings. You need to pick
Thomas H. wrote:
> maybe its by design (to not insert badly encoded characters into the
> utf8 encoded logs)? nevertheless to debug those faulty programm/codes,
> it would help to see what query provokes the error...
Well, the problem is mainly that there is no query, because the bytes arriving
a
I cannot dump the thing
somewhere for inspection (it contains confidential information), but I
can assist in inspecting the contents.
--
/ Peter Schuller
PGP userID: 0xE9758B7D or 'Peter Schuller <[EMAIL PROTECTED]>'
Key retrieval: Send an E-Mail to [EMAIL PROTECTED]
E-Mail: [EMAIL PROTECTED] Web: http://www.scode.org
pgpooalCAihTU.pgp
Description: PGP signature
-read the documentation on this immediately. If this is
the problem, I do apologies for the noise and people's time.
--
/ Peter Schuller
PGP userID: 0xE9758B7D or 'Peter Schuller <[EMAIL PROTECTED]>'
Key retrieval: Send an E-Mail to [EMAIL PROTECTED]
E-Mail: [EMAIL PROTECTED] Web: http://www.scode.org
pgp8RkHOz5fkY.pgp
Description: PGP signature
to
do...
I sincerely apologies for wasting people's time; thank you VERY much
for the quick response!
I will go hide in a corner now...
--
/ Peter Schuller
PGP userID: 0xE9758B7D or 'Peter Schuller <[EMAIL PROTECTED]>'
Key retrieval: Send an E-Mail to [EMAIL PROTECTED]
E-Mail: [
Cindy Moore wrote:
I looked through the lists and couldn't figure out where else to put
this. I'm trying to create indices on xpath expressions for columns
of type xml.
I'm running postgres version 8.3.3, running on solaris.
Text=# create index trclass on lsj_xml ((xpath
('//[EMAIL PROTECTED]"t
Andreas Peer wrote:
Well, the use case is a strange one... I would like to use a varchar()
column for storing a variable-length vector of integers. The numbers are
represented by the codepoints. Therefore, I need to sort them as binary
data, not as characters. I would often need to get all the
David Fetter wrote:
On Sun, Sep 28, 2008 at 11:51:49AM -0700, austijc wrote:
That's going to be a problem for the continued viability of
Postgres.
Funny, I thought running a DBMS over a known-unreliable storage system
was a problem for the continued viability of Oracle. When, not if,
people l
ivocs admin wrote:
initdb -E ISO-8859-1 -D data/
This is probably not a good idea. You should specify a locale and let
initdb figure out the matching encoding. Otherwise you might end up
with an incompatible locale/encoding combination. (initdb would
probably not even allow this to procee
Jussi Pakkanen wrote:
However when I try to count the amount of distinct codes, I get this:
EXPLAIN SELECT COUNT(DISTINCT code) FROM log;
QUERY PLAN
-
Aggregate (cost=100801488.
Dmitry Orlov wrote:
if I issue create tablespace user_ts location
'/var/lib/postgresql/8.3/main/pg_tblspc' then appears nested links in
/var/lib/postgresql/8.3/main/pg_tblspc. So should avoid to create
tablespaces in pg_tblspc
If this is the location you give it, why should it avoid creating
t
Tom Lane wrote:
Peter Eisentraut <[EMAIL PROTECTED]> writes:
ivocs admin wrote:
The database cluster will be initialized with locale uk_UA.KOI8-U.
could not determine encoding for locale "uk_UA.KOI8-U": codeset is "KOI8-U"
initdb: could not find suitable text searc
Tony Marston wrote:
The following bug has been logged online:
Bug reference: 4465
Logged by: Tony Marston
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.4
Operating system: Windows XP
Description:GROUP BY is not to SQL standard
Details:
The Postgresql im
Tony Marston wrote:
I think your definition of "Feature T301 Functional Dependencies" is
extremely questionable. A functional dependency in relational theory
automatically exists where a non-key column on a table is functionally
dependent on the key of that table. It is not something that can be
Tony Marston wrote:
You are still missing the point - "functional dependencies" is not a
separate module that can be turned on or off with code,
It is in the SQL standard.
they are inherent in
the database design. According to relational theory any non-key field on a
table is functionally dep
Harvey, Allan AC wrote:
Zdenek,
Hmm, It does not look good. Your OS does not return proper
information about
codeset. Following code is broken:
setlocale(LC_CTYPE, ctype);
sys = nl_langinfo(CODESET);
sys = strdup(sys);
See
http://www.opengroup.org/onlinepubs/00969539
The following bug has been logged online:
Bug reference: 4502
Logged by: Peter Mengaziol
Email address: [EMAIL PROTECTED]
PostgreSQL version: EDB 8.3.0.12
Operating system: Mac OS X 10.4.11
Description:pgAdmin Display Refresh Rate cannot be less that 7 secs
Details
Kevin Field wrote:
Section 9.2 in the docs say, 'The ordinary comparison operators yield null
(signifying "unknown") when either input is null.' This applies to other
operators too. For example, the result of tacking an unknown value onto a
known one is unknown, because you don't know what exac
Tom Lane wrote:
It's really all kind of messy ... we need to trade off simplicity of
definition, ease of use, backwards compatibility, and standards
compliance (though the standard has only 1-D arrays so it's of just
limited help here).
AFAICT, the standard would certainly allow a type specific
Sushil wrote:
I am trying to exploit XML features of PostgreSQL 8.3.0 DB.
You should upgrade to the latest 8.3 release, currently 8.3.5. There
were some fixes in this area (and other areas).
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscriptio
Sushil wrote:
*postgres: postgres testdb [local] SELECT: symbol lookup error:
postgres: postgres testdb [local] SELECT: undefined symbol:
xmlNewTextWriterMemory*
Your problem appears to be here. Check you libxml installation. Maybe
someone forgot to export this symbol.
--
Sent via pgsql-
On Monday 24 November 2008 23:37:02 Barry Reddy wrote:
> Can anyone clarify if this apparent contradiction is an oversight ? Old
> documentation with new archiving documentation patched on, with no
> attention paid to the seeming contradiction on guidelines for filesystem
> backups of a running PG
On Friday 28 November 2008 15:31:51 Barry Sanford wrote:
> looking at PostgreSQL, I noticed that you have various geometric data types
> as standard. However, I was somewhat surprised that you are attempting to
> implement the 'line' type via a two point scheme. While this is okay for
> line segm
On Thursday 04 December 2008 13:03:16 wstrzalka wrote:
> This is my output on Windows:
> ---
>-
> D:\Code>pg_dump -U postgres -d test -n public
> pg_dump: too many command-line arguments (first
On Sunday 07 December 2008 01:02:05 Bruce Momjian wrote:
> Where are we on this?
Some of this has been fixed. But a lot of the code has been moved around
between 8.3 and 8.4, so we can't just take take the patches as is. If
Richard is still interested, I suggest he try out 8.4 and then submit
Vincent Predoehl wrote:
I was running fink and it said to report this:
configure: WARNING: krb5.h: present but cannot be compiled
configure: WARNING: krb5.h: check for missing prerequisite headers?
configure: WARNING: krb5.h: see the Autoconf documentation
configure: WARNING: krb5.h: sec
On Saturday 20 December 2008 02:15:05 Vincent Predoehl wrote:
> On Dec 19, 2008, at 3:48 AM, Peter Eisentraut wrote:
> > Vincent Predoehl wrote:
> >> I was running fink and it said to report this:
> >> configure: WARNING: krb5.h: present but cannot be compiled
>
On Friday 26 December 2008 01:12:26 Tom Lane wrote:
> More generally, there are a *whole lot* of ridiculous inefficiencies
> in our information_schema views; I'm surprised there haven't been
> more complaints about them. Sometime someone ought to go through
> the whole set and see what other refac
Vincent Predoehl wrote:
On Dec 20, 2008, at 9:15 AM, Peter Eisentraut wrote:
On Saturday 20 December 2008 02:15:05 Vincent Predoehl wrote:
On Dec 19, 2008, at 3:48 AM, Peter Eisentraut wrote:
Vincent Predoehl wrote:
I was running fink and it said to report this:
configure: WARNING: krb5.h
Vincent Predoehl wrote:
This is not the config.log file from the run that produced the warning
you are complaining about.
I did run configure several times since the error. I know nothing of
autoconf and didn't know to save the config.log file. I just ran
./configure again for 8.3.5 and did
On Tuesday 30 December 2008 17:49:16 Richard Evans wrote:
> I've taken a look at the current development snapshot ane made a new
> patch. This is against the snapshot source dated 2008-12-30.
Half of this patch appears to attempt to fix not cross-compilation problems,
but out-of-tree builds (vpa
Richard Evans wrote:
I've taken a look at the current development snapshot ane made a new
patch. This is against the snapshot source dated 2008-12-30.
This is now committed.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgr
On Tuesday 06 January 2009 02:03:14 Tom Lane wrote:
> I don't think there's a bug here, at least not in the sense that it
> isn't Operating As Designed. But it does seem like we could do with
> some more/better documentation about exactly how FOR UPDATE works.
> The sequence of operations is evide
On Thursday 22 January 2009 15:39:00 Sergey Burladyan wrote:
> seb=# select xpath('/русский/text()', v::xml) from (select
> xml('<русский>язык')) as x(v);
> ERROR: could not parse XML data
> DETAIL: Entity: line 1: parser error : Input is not proper UTF-8, indicate
> encoding !
> Bytes: 0xF0 0xF3
Mykola Stryebkov wrote:
Hi,
# psql83 template1
Password:
Welcome to psql83 8.3.5, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help with psql commands
\g or terminate with semicolon to execute query
The following bug has been logged online:
Bug reference: 4671
Logged by: Peter Woodward
Email address: pe...@petew.org.uk
PostgreSQL version: 8.3
Operating system: FreeBSD 7.0
Description:Cluster Initialisation Fails on FreeBSD
Details:
The following script shows
Heikki Linnakangas wrote:
xuan--2009.03--submitbug--support--postgresql@baldauf.org wrote:
When executing
"ALTER TABLE sometable ALTER COLUMN somecolumn TYPE VARCHAR(7)", the
whole
table is re-written, and this rewrite takes many hours. During these
hours,
all writers on this table stall,
vikas wrote:
The following bug has been logged online:
Bug reference: 4690
Logged by: vikas
Email address: vikas.du...@newgen.co.in
PostgreSQL version: PostgreSQL 7.3
Time to upgrade.
Operating system: i686-pc-linux-gnu
Description:an select query is not using th
The following bug has been logged online:
Bug reference: 4692
Logged by: Peter Much
Email address: p...@citylink.dinoex.sub.org
PostgreSQL version: 8.2.7
Operating system: FreeBSD 6.3
Description:VACUUM: write to WAL gets very slow and seems redundant
Details
The following bug has been logged online:
Bug reference: 4697
Logged by: Peter Guarino
Email address: peterguar...@earthlink.net
PostgreSQL version: 8.3.3
Operating system: Suse 10.x
Description:to_tsvector hangs on input
Details:
Certain strings involving the
On Monday 30 March 2009 17:34:36 Martin Pitt wrote:
> recently, I started to get quite a bunch of bug reports a la
> "PostgreSQL fails to start due to too little shared memory" [1]. I
> have never seen this before, neither in Debian, so I guess the
> SHMMAX defaults changed somewhat in Linux 2.6.27
On Sunday 05 April 2009 13:44:37 Stefano Salvador wrote:
>select sin(pi());
>
> returns: 1.2246
>
> or:
>
>select cos(pi()/2);
>
> returns: 6.123
>
> but sin and cos are limited between -1 and 1 !!!
I get
=> select sin(pi());
sin
--
1.22460635382238e-16
(1 ro
On Friday 10 April 2009 08:39:33 Martin Pitt wrote:
> Tom Lane [2009-04-10 1:15 -0400]:
> > Martin Pitt writesyuqhom#3:
> > > The test suite detected one regression in libpq, though: Setting
> > > $PGHOST now complains about a missing root.crt, although this is only
> > > relevant on the server s
On Friday 10 April 2009 17:13:55 Martin Pitt wrote:
> However, we can't afford to break existing installations. If a user
> has 8.4 installed locally, he'll use libpq from 8.4, and suddenly he
> could not connect to a remote SSL 8.3 cluster any more. So the check
> needs at least be turned into a w
On Friday 10 April 2009 21:27:54 Stephen Frost wrote:
> I agree with this. Avoiding spoofing is good, but so is on the wire
> encryption even if you don't have anti-spoofing. This is a reasonable
> set-up and we shouldn't just fail on it.
This whole debate hinges on the argument that encryption
On Friday 10 April 2009 21:32:29 Stephen Frost wrote:
> A properly configured server could cause a failure too unless the client
> is *also* properly configured. Sure, it's good for people to do. No, I
> don't think we should break things if people don't build out a whole PKI
> for PG and configu
On Friday 10 April 2009 22:44:44 Bruce Momjian wrote:
> The problem is that libpq doesn't have any ability to warn/prompt like
> SSH and web browsers do, so I think Magnus patterned the libpq behavior
> around cases where warning/prompt failed in these environments.
>
> I am not saying the current
On Friday 10 April 2009 21:32:29 Stephen Frost wrote:
> Uh, no, the right fix is to have a warning/prompt (as pretty much all
> web browsers today do) but then continue to connect.
On that matter, it is interesting to observe where web browsers are heading
today.
It used to be that web browsers
On Friday 10 April 2009 22:50:02 Tom Lane wrote:
> Peter Eisentraut writes:
> > On Friday 10 April 2009 21:27:54 Stephen Frost wrote:
> >> I agree with this. Avoiding spoofing is good, but so is on the wire
> >> encryption even if you don't have anti-spoofing.
On Sunday 12 April 2009 01:58:26 Magnus Hagander wrote:
> "sslmode=prefer" honestly makes no sense - if I don't care if it ends up
> encrypted or not (which it means), then why not just run with SSL off
> and not have to deal with the overhead?
Perhaps a large part of the problem at hand is in fac
On Sunday 12 April 2009 12:52:53 Magnus Hagander wrote:
> This is a different way to do bruces suggestion of a different
> default. That's possibly even clearer. So I can definitely go with
> this, but I think two different parameters makes it more clear and is
> better.
I think altogether c
On Tuesday 14 April 2009 17:05:45 Martin Pitt wrote:
> Of course I assumed that the server and client are on different
> systems. If they are on the same, then we just use the Unix socket and
> don't need all this SSL fuss at all.
That's what you think. Just read the hackers thread about SSL over
On Monday 20 April 2009 11:19:04 Magnus Hagander wrote:
> Bruce Momjian wrote:
> > Magnus Hagander wrote:
> >> On 14 apr 2009, at 04.33, Bruce Momjian wrote:
> >>> Magnus Hagander wrote:
> > I would actually call the two parameters 'verify-cert' and 'verify-
> > cn',
> > and document t
On Tuesday 21 April 2009 14:04:01 fduerr wrote:
> CREATE OR REPLACE FUNCTION eq_int_bool(INTEGER, BOOLEAN) RETURNS BOOLEAN AS
> 'SELECT CAST($1 AS BOOLEAN)=$2;' LANGUAGE SQL IMMUTABLE;
> CREATE OPERATOR = (
> LEFTARG=INTEGER,
> RIGHTARG=BOOLEAN,
> PROCEDURE=eq_int_bool,
> COMMUTATOR= = ,
> NE
Dear all,
since upgrading Ruby from 1.8.6.287 to 1.8.7.72, and recompiling
PL/ruby 0.5.0, functions written in PL/ruby may ignore their
given parameters and instead compute with undefined values,
providing nonsense results.
The test-suite provided with PL/ruby will show the problem.
Upgrading
The following bug has been logged online:
Bug reference: 4801
Logged by: Peter Much
Email address: p...@citylink.dinoex.sub.org
PostgreSQL version: 8.2.13
Operating system: FreeBSD 7.2
Description:Performance failure: 600 MB written to each WAL log
Details:
Server
elog
of the stuff that is actually written to WAL.
Maybe then we find something that is not limited to VACUUM FULL, or
maybe we find something that does NOT do greater havoc only by good
luck. Or maybe it is just the way it should work...
best regards,
Peter
--
Sent via pgsql-bugs mailing list (pgs
is really
eager to dig into the old stuff and search for strange problems
there. That's an argument, I can understand.
best regards,
Peter
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Friday 15 May 2009 01:07:11 Hershel Fisch wrote:
> Hi, I realized that sorting date is done like text and not numeric (dates)
> e.g. SELELCT * FROM database_name ORDER BY date ASC
>
> Return order
>
> 3/02/09
> 4/19/09
> 4/2/09
>
> Thanks,
This report would make a lot more sense if you posted
On Thursday 21 May 2009 10:52:33 Целуйко Дмитрий wrote:
> When DDL triggers will be supported by PostgreSQL?
There are currently no concrete plans for that, but if someone comes up with a
good design and implementation, it could be acceptable. But don't hold your
breath.
--
Sent via pgsql-bug
The following bug has been logged online:
Bug reference: 4824
Logged by: Peter Koczan
Email address: pjkoc...@gmail.com
PostgreSQL version: 8.4beta2
Operating system: Red Hat Enterprise Linux 5.3
Description:KRB5/GSSAPI authentication fails when user != principal
n, that's a fundamental breakage. One of the major points
of Kerberos is that, for anything that talks Kerberos, you are the
principal in that ticket. I understand the desire to change some of
that old code, but why is that principal being ignored?
Peter
--
Sent via pgsql-bugs mailing list (pgsq
I don't know if it's much use now, but here you go.
On Wed, May 27, 2009 at 3:15 PM, Magnus Hagander wrote:
> We are certainly *supposed* to do that. And we have been doing that. So
> if that's not done, it's been broken in 8.4 (most likely by me).
>
> Peter, ar
On Wed, May 27, 2009 at 5:16 PM, Tom Lane wrote:
> What this still leaves us with is whether that change is a bad idea or
> not. I still think it's OK, but maybe Peter can point to something
> else.
I recompiled postgres with the auth.c patch.
This is only an issue if you are try
On Thu, May 28, 2009 at 1:30 PM, Tom Lane wrote:
> Peter Koczan writes:
>> It was rather convenient to know that whatever Kerberos principal was
>> used was going to be the database user.
>
> Isn't that still true? (Modulo the auth.c bug fix of course.) The only
On Thu, May 28, 2009 at 2:07 PM, Peter Koczan wrote:
> On Thu, May 28, 2009 at 1:30 PM, Tom Lane wrote:
>> Peter Koczan writes:
>>> It was rather convenient to know that whatever Kerberos principal was
>>> used was going to be the database user.
>>
>> Isn
On Thursday 28 May 2009 13:31:16 Itagaki Takahiro wrote:
> Here is a patch to fix the bug. I added a parameter 'encode' to
> map_sql_value_to_xml_value() and pass false for xml attributes.
I have committed your patch with minor editing. Thanks.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@po
On Sunday 31 May 2009 20:00:44 Tom Lane wrote:
> Itagaki Takahiro writes:
> > Here is a patch to fix the bug. I added a parameter 'encode' to
> > map_sql_value_to_xml_value() and pass false for xml attributes.
>
> One thing I was wondering about, which is sort of highlighted by your
> patch, is wh
On Wednesday 10 June 2009 18:02:45 Dhaval Jaiswal wrote:
> Yes, there isn't a use case for a month value outside 1-12, i found this
> due a typo.
What Would Oracle Do?
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.o
On Wednesday 24 June 2009 04:59:05 Jim Michaels wrote:
> If you are looking for hash collision protection, start looking at SHA-256
> or SHA-512.
Well, are we looking for that? We are not using MD5 for digital signatures.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make
On Friday 26 June 2009 00:04:02 Alfred Monticello wrote:
> in doc/Makefile, tar is run to extract an archive with xf options. Needs
> oxf to map to owner of person running tar, otherwise Invalid Argument
> occurs and the Makefile errors out.
>
> A better solution might be to compact postgres as UID
On Saturday 27 June 2009 15:06:30 Ricardo wrote:
> Need support for acent sensitive in UTF-8, in clause like SQL.
This is not a bug. But you may find this helpful:
http://wiki.postgresql.org/wiki/Strip_accents_from_strings
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make
The following bug has been logged online:
Bug reference: 4894
Logged by: Peter Schuller
Email address: peter.schul...@infidyne.com
PostgreSQL version: CVS
Operating system: N/A
Description:[patch] documentation bug on 'include' directive
Details:
The doc
e. That said
perhaps it has been changed in CVS; I didn't test that, but only had a
quick look at the code.
Since I thought the lack of = was indeed incorrect syntax I claimed
CVS in the bug report since the documentation has that syntax in CVS,
but I didn't test the CVS version of the
your time. I should
have confirmed where the error message came from.
--
/ Peter Schuller
PGP userID: 0xE9758B7D or 'Peter Schuller '
Key retrieval: Send an E-Mail to getpgp...@scode.org
E-Mail: peter.schul...@infidyne.com Web: http://www.scode.org
pgpPkr3qEEV4q.pgp
Description: PGP signature
On Thursday 02 July 2009 02:45:24 John R Pierce wrote:
> ajmcello wrote:
> > The only downside with adding o to tar that I can see is if it isn't
> > supported by a non-GNU version of tar.
>
> On solaris 9 and 10 at least, tar -o means set ownership of extracted
> files to the runner and not the ui
On Thursday 02 July 2009 09:56:35 Peter Eisentraut wrote:
> On Thursday 02 July 2009 02:45:24 John R Pierce wrote:
> > ajmcello wrote:
> > > The only downside with adding o to tar that I can see is if it isn't
> > > supported by a non-GNU version of tar.
> >
The following bug has been logged online:
Bug reference: 4899
Logged by: Peter Headland
Email address: pheadl...@actuate.com
PostgreSQL version: 8.4.0
Operating system: Windows
Description:Open parenthesis breaks query plan
Details:
In a moderate-size table
The following bug has been logged online:
Bug reference: 4900
Logged by: Peter Headland
Email address: pheadl...@actuate.com
PostgreSQL version: 8.4.0
Operating system: Windows
Description:Query planner misses obvious optimization on ordered
UNION DISTINCT
Details
shandling parentheses. I don't understand why
parentheses should be significant inside a string literal in the first place.
Also, just to be 100% clear, the open paren can be anywhere in the string, so a
comparison to 'abcdefgh(ijklmnop' still triggers the bug.
--
Peter Headl
ans is that the initial symbol with the name of the
index underneath vanishes when there is an unmatched open parenthesis. I
have been unable to find an explanation of the symbols used in pgAdmin
III - is there such a thing anywhere?
If we are agreed that the issue is a bug in pgAdmin III, please a
As I said further down my previous e-mail, it looks as if the optimizer
is just fine, and the problem is simply a bug in the way pgAdmin III
parses and displays EXPLAIN ANALYZE output in its graphical view.
--
Peter Headland
Architect - e.Reports
Actuate Corporation
-Original Message
On Monday 13 July 2009 19:17:49 David Kerr wrote:
> We're using SLES 11, and uuid-ossp isn't delivered in the
> postgresql-contrib package, we opened a case with Novell and this was their
> reply:
> [some nonsense]
I'm sorry to say that SUSE just isn't a good source if you want to do serious
Post
On Friday 17 July 2009 11:12:41 Jan-Ivar Mellingen wrote:
> 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!
> This is a dramatical difference, but I cann
On Friday 17 July 2009 12:45:47 Mikael Krantz wrote:
> It might be that your column may be NULL as well as TRUE or FALSE. I
> am no expert in this matter though.
Nulls also need to be considered when attempting to substitute purportedly
equivalent clauses. But in this case it wouldn't actually m
1 - 100 of 900 matches
Mail list logo
