Josh Berkus writes:
> Now that I'm beginning serious performance testing of clock-sweep, I
> was going back through the lock discussion and am not sure what the
> patch that actually went in 3 weeks ago consisted of. Is it
> clock-sweep with a used/unused bit or a counter? How is it handling
> s
Josh Berkus wrote:
Oh, and incidentally, can I use the same database files for 8.0.2 and 8.1cvs
3/10/05?
No.
-Neil
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL P
Tom,
Now that I'm beginning serious performance testing of clock-sweep, I was going
back through the lock discussion and am not sure what the patch that actually
went in 3 weeks ago consisted of. Is it clock-sweep with a used/unused bit
or a counter? How is it handling seq scans?
Oh, and i
On 2005-04-10, "John Hansen" <[EMAIL PROTECTED]> wrote:
> That's right, dono how I missed that one, but looks correct to me, and
> is in line with the code in ConvertUTF.c from unicode.org, on which I
> based the patch, extended to support 6 byte utf8 characters.
Frankly, you should probably de-ex
On Sat, Apr 09, 2005 at 21:02:34 +0200,
[EMAIL PROTECTED] wrote:
> Is there a way to set case sensitivity on?
In what context?
If you are talking about mixed case table or column names, then you need
to quote them with double quotes (").
---(end of broadcast)---
People:
(HACKERS: Please read this entire thread at
http://archives.postgresql.org/pgsql-performance/2005-04/msg00179.php
Sorry for crossing this over.)
> > The larger point is that writing an estimator for an SRF is frequently a
> > task about as difficult as writing the SRF itself
>
> True, a
Tom Lane wrote:
> Yeah? Cool. Does John's proposed patch do it "correctly"?
>
> http://candle.pha.pa.us/mhonarc/patches2/msg00076.html
Some comments on that patch:
Doesn't pg_utf2wchar_with_len need changes for the longer sequences?
UtfToLocal also appears to need changes.
If we support seq
In working on the newsysviews project we've discovered that there's no
definitive way to determine if a cast is a system cast (system as in
part of postgresql/created by createdb) or not. What pg_dump does (and
what we're doing now for lack of a better solution) is any cast that
doesn't involve a u
Bruce,
> If everyone else is OK with having it fail, that is fine with me, but I
> wanted to make sure folks saw this was happening. ÂI basically saw no
> discussion that we were disabling that syntax. Â[CC moved to hackers.]
I believe we hashed this out when we added add_missing_from back in 7.3
Ola' juan,
> Is there a way to set case sensitivity on?
>
No. Discussions about this thread are in the archives
(http://archives.postgresql.org). Take a look at:
http://www.postgresql.org/docs/8.0/interactive/sql-syntax.html#SQL-SYNTAX-IDENTIFIERS
Euler Taveira de Oliveira
euler[at]yahoo_com_br
>On 2005-04-10, Tom Lane wrote:
>> Andrew - Supernews
writes:
>>> I think you will find that this impression is actually false. Or
that at
>>> the very least, _correct_ verification of UTF-8 sequences will still
>>> catch essentially all cases of non-utf-8 input mislabelled as utf-8
>>> while all
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> After the "TO" there is one space and the cursor is after that space
> I press tab and I get
>
> leda=# ALTER TABLE any_table RENAME TO TO
What is happening is that psql is simply assuming that the first "TO"
may be the name of a column you are ab
Is there a way to set case sensitivity
on?
Thanks in advance
juan
Tom Lane wrote:
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
On Wed, Apr 06, 2005 at 06:09:37PM -0400, Tom Lane wrote:
Can anyone suggest a more general rule? Do we need for example to
consider whether the relation membership is the same in two clauses
that might be opposite sides of a range restric
Hi,
I know that you can not (and maybe should not) install triggers
on system catalogs. But, if I want to catch certain DDL events
(such as adding a column), is there any way to do it in PostgreSQL?
Maybe, it could be useful that the triggers (installed on normal tables)
can be fired not only b
Hello...
On Tue, 05 Apr 2005 02:28:23 -0400, [EMAIL PROTECTED] (Tom Lane)
wrote:
>
>How does Oracle's PL/SQL handle this?
On ORACLE a FUNCTION MUST return a value. If the FUNCTION doesn't
return a value Oracle give a 'hint' on FUNCTION compilation and error
on SELECT function invocation: ORA-06
Dear Sir,
I' ve recently join to PostGreSql community. I'm testing it on a local
network and I'm very found of it .
However there are a few things that I'd like to understand better.
As far as i realise, every time the Server validates a wrong value for an
input it Raises an Exception with t
On 2005-04-10, Tom Lane <[EMAIL PROTECTED]> wrote:
> Andrew - Supernews <[EMAIL PROTECTED]> writes:
>> I think you will find that this impression is actually false. Or that at
>> the very least, _correct_ verification of UTF-8 sequences will still
>> catch essentially all cases of non-utf-8 input m
Tom Lane wrote:
"Ramy M. Hassan" <[EMAIL PROTECTED]> writes:
The genericcostestimate function is currently static. This limits the
development of new access methods as loadable modules without touching
pgsql sources. Currently I have to include a copy of the function in the
module, which is o
On Sun, 10 Apr 2005, Peter Eisentraut wrote:
Bruce Momjian wrote:
So, we do have a bug, and we are probably going to need to fix it in
8.0.X.
This has never worked in all the years we have had Unicode
functionality, so I don't understand why we have to rush to fix it now.
Certainly, it ought to be
"Ramy M. Hassan" <[EMAIL PROTECTED]> writes:
> The genericcostestimate function is currently static. This limits the
> development of new access methods as loadable modules without touching
> pgsql sources. Currently I have to include a copy of the function in the
> module, which is obviously to
Andrew - Supernews <[EMAIL PROTECTED]> writes:
> On 2005-04-10, Tom Lane <[EMAIL PROTECTED]> wrote:
>> The impression I get is that most of the 'Unicode characters above
>> 0x1' reports we've seen did not come from people who actually needed
>> more-than-16-bit Unicode codepoints, but from peop
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Bruce Momjian wrote:
>> So, we do have a bug, and we are probably going to need to fix it in
>> 8.0.X.
> This has never worked in all the years we have had Unicode
> functionality, so I don't understand why we have to rush to fix it now.
> Certainl
Hi,
The genericcostestimate function is currently static. This limits the
development of new access methods as loadable modules without touching
pgsql sources. Currently I have to include a copy of the function in the
module, which is obviously too bad.
Is there any reason to keep this function
On 2005-04-10, Tom Lane <[EMAIL PROTECTED]> wrote:
> The impression I get is that most of the 'Unicode characters above
> 0x1' reports we've seen did not come from people who actually needed
> more-than-16-bit Unicode codepoints, but from people who had screwed up
> their encoding settings and
Bruce Momjian wrote:
> So, we do have a bug, and we are probably going to need to fix it in
> 8.0.X.
This has never worked in all the years we have had Unicode
functionality, so I don't understand why we have to rush to fix it now.
Certainly, it ought to be fixed, but not in a minor release.
-
[ This email to hackers from last night got lost so I am remailing.]
Tom Lane wrote:
> "John Hansen" <[EMAIL PROTECTED]> writes:
> >> That is backpatched to 8.0.X. Does that not fix the problem reported?
>
> > No, as andrew said, what this patch does, is allow values > 0x and
> > at the sam
27 matches
Mail list logo