Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> ... This also means that the start byte can never start with 7 or 8
> ones, that is illegal and should be tested for and rejected. So the
> longest utf-8 sequence is 6 bytes (and the longest character needs 4
> bytes (or 31 bits)).
Tatsuo would know m
Ahh, but that's not the case. You cannot just delete the check, since
not all combinations of bytes are valid UTF8. UTF bytes FE & FF never
appear in a byte sequence for instance.
UTF8 is more that two bytes btw, up to 6 bytes are used to represent an
UTF8 character.
The 5 and 6 byte characters are
On Sat, 2004-08-07 at 06:06, Tom Lane wrote:
> Now it's entirely possible that the underlying support is a few bricks
> shy of a load --- for instance I see that pg_utf_mblen thinks there are
> no UTF8 codes longer than 3 bytes whereas your code goes to 4. I'm not
> an expert on this stuff, so I d
Oliver Elphick <[EMAIL PROTECTED]> writes:
> glibc provides various routines (mb...) for handling Unicode. How many
> of our supported platforms don't have these?
Every one that doesn't use glibc. Don't bother proposing a glibc-only
solution (and that's from someone who works for a glibc-only co
On Fri, 6 Aug 2004, Marc G. Fournier wrote:
>
> due to a googlebot effect, I had to shut it down temporarily ...
what's about /robots.txt ?
>
>
> Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
> Email: [EMAIL PROTECTED] Yahoo!: yscrappy IC
On Sat, 7 Aug 2004, Tom Lane wrote:
> shy of a load --- for instance I see that pg_utf_mblen thinks there are
> no UTF8 codes longer than 3 bytes whereas your code goes to 4. I'm not
> an expert on this stuff, so I don't know what the UTF8 spec actually
> says. But I do think you are fixing the
Possibly, since I got it wrong once more
About to give up, but attached, Updated patch.
Regards,
John Hansen
-Original Message-
From: Oliver Elphick [mailto:[EMAIL PROTECTED]
Sent: Saturday, August 07, 2004 3:56 PM
To: Tom Lane
Cc: John Hansen; Hackers; Patches
Subject: Re: [HACKER
"John Hansen" <[EMAIL PROTECTED]> writes:
> My apologies for not reading the code properly.
> Attached patch using pg_utf_mblen() instead of an indexed table.
> It now also do bounds checks.
I think you missed my point. If we don't need this limitation, the
correct patch is simply to delete the
Bruce Momjian <[EMAIL PROTECTED]> writes:
> When we do a PITR recovery based on xid, does it stop recovery based on
> the start of the xid or the commit of the xid?
You can stop either "before" or "after" that commit. See
recovery.conf.sample (I don't think it's documented anywhere else
yet :-(),
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> Yeah, those are all bug fixes and okay for post-beta I think. But which
>> two tablespace failures are you thinking of exactly? The last couple
>> weeks have been a bit of a blur for me...
> http://groups.google.com.au/groups?q=tablespaces+g
Jan Wieck wrote:
> On 8/6/2004 9:04 PM, Bruce Momjian wrote:
>
> > Updated. Thanks.
>
> I thought we want to have the feature activated ... I reversed your
> change and brought guc.c in sync instead.
Uh, if the guy is doing a vacuum at night, does he want the delay?
Seems someone should have
Jan Wieck wrote:
> On 8/6/2004 9:04 PM, Bruce Momjian wrote:
>
> > Updated. Thanks.
>
> I thought we want to have the feature activated ... I reversed your
> change and brought guc.c in sync instead.
OK.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED]
When we do a PITR recovery based on xid, does it stop recovery based on
the start of the xid or the commit of the xid? And if you say
recovery_target_inclusive =true, does it recover that xid while not
recoverying other xids that are higher but committed sooner than the
target xid?
-
On 8/6/2004 9:04 PM, Bruce Momjian wrote:
Updated. Thanks.
I thought we want to have the feature activated ... I reversed your
change and brought guc.c in sync instead.
Jan
---
Matthew T. O'Connor wrote:
Related to autovacuu
My apologies for not reading the code properly.
Attached patch using pg_utf_mblen() instead of an indexed table.
It now also do bounds checks.
Regards,
John Hansen
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Saturday, August 07, 2004 4:37 AM
To: John Hansen
Cc: Ha
Joe Conway <[EMAIL PROTECTED]> writes:
> The attached patch suppresses trailing whitespace, but allows embedded
> whitespace in unquoted elements as discussed above. It also rejects some
> previously accepted cases that were just too strange to be correct:
> -- Postgres 8.0, with the patch
> --
due to a googlebot effect, I had to shut it down temporarily ...
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664
---(end of broadcast)---
TI
Tom Lane wrote:
I think that suppressing unquoted trailing whitespace is probably
reasonable. I'm much less enthusiastic about rejecting unquoted
embedded whitespace, though. I think that's significantly likely
to break apps, and it doesn't seem like it's really needed to have
sane behavior. The
Oliver Jowett wrote:
> Merlin Moncure wrote:
>
> > Another way to deal with the problem is to defer plan generation until
> > the first plan execution and use the parameters from that execution.
>
> When talking the V3 protocol, 7.5 defers plan generation for the unnamed
> statement until parame
On Sat, Aug 07, 2004 at 01:34:20AM +0200, Gaetano Mendola wrote:
> Alvaro Herrera wrote:
>
> >Yeah. I included your tab-complete patch in the patch I sent to
> >pgsql-patches, which later Tom reworked and applied. His CVS comment
> >didn't mention the tab completion change. This isn't surprisin
Updated. Thanks.
---
Matthew T. O'Connor wrote:
> Related to autovacuum work, I was looking into the new vacuum delay
> functionality. I might be missing something, but I can't find anything
> on it in the developer docs.
Alvaro Herrera wrote:
On Tue, Aug 03, 2004 at 06:42:03PM +0200, Gaetano Mendola wrote:
I'm reading some comment on CVS and I seen this comment
for tab-complete.c revision 1.109:
Fix subtransaction behavior for large objects, temp namespace, files,
password/group files. Also allow read-only subtra
On Fri, 06 Aug 2004 18:55:49 -0400, Tom Lane <[EMAIL PROTECTED]> wrote:
>You think there's a serious risk of failure there ;-) ?
Not on my hardware...
Servus
Manfred
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an
Manfred Koizar <[EMAIL PROTECTED]> writes:
> referring to
> | -- we assume this will take longer than 1 second:
> | select count(*) into x from tenk1 a, tenk1 b, tenk1 c;
> Maybe
> SELECT sleep('0:0:2'::interval);
> as used in regress/sql/stats.sql is a better way to ensure that the
On Sat, 31 Jul 2004 21:24:33 -0400, Tom Lane <[EMAIL PROTECTED]> wrote:
>Exactly. There's a proof-of-concept test at the bottom of
>regress/sql/plpgsql.sql, wherein a function gets control back
>from a query that would have run for an unreasonably long time.
referring to
| -- we assume this w
Tom Lane wrote:
Gaetano Mendola <[EMAIL PROTECTED]> writes:
$ pg_dump -p 5433 test
pg_dump: could not parse ACL list ([0:1]={postgres=UC/postgres,=UC/postgres}) for object
"public" (SCHEMA)
Ugh. This is an unforeseen side effect of Joe's recent changes to make
array_out emit dimension info.
Sorry
On Tue, Aug 03, 2004 at 06:42:03PM +0200, Gaetano Mendola wrote:
> I'm reading some comment on CVS and I seen this comment
> for tab-complete.c revision 1.109:
>
> Fix subtransaction behavior for large objects, temp namespace, files,
> password/group files. Also allow read-only subtransactions o
"John Hansen" <[EMAIL PROTECTED]> writes:
> Attached, as promised, small patch removing the limitation, adding
> correct utf8 validation.
Surely this is badly broken --- it will happily access data outside the
bounds of the given string. Also, doesn't pg_mblen already know the
length rules for UT
On Fri, 2004-08-06 at 10:53, Joshua D. Drake wrote:
> Although the gap still exists within the environment itself, one
> significant advantage with PostgreSQL is you can use a more native (to
> the programmer anyway) language to generate your logic.
>
> With PostgreSQL alone you can use plPerl,
The major disadvantage is that the development environment and tools for
in-database languages aren't nearly as rich as your typical standalone
environment, which makes programming a pain in the ass for many types of
codes. I might have missed something in the intervening years, but I
Although th
Done.
---
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Is this the proper item description?
>
> > * Remove comments on postgresql.conf variables
>
> It could easily be taken to mean removing th
Hi,
When using psql I can list the tables and sequences by typing:
\d
futhermore:
\dt lists tables
\ds lists sequences
\d tablename lists that table.
etc. etc.
But how can I get a listing of all used triggers on a certain table?
Thanks for your time
Regards,
Erwin Moller
ApocalypseKnight wrote:
>
> Learn how to Hack into computers,websites,Aol/Yahoo/Msn accounts,view
> webcams without permission,computer programming,and much,MUCH more at:
>
> http://stop.to/Hacker
>
> and:
>
> http://groups.msn.com/SecretsoftheCyberWarrior
>
> ApocalypseKnight
I think Apocal
Attached, as promised, small patch removing the limitation, adding
correct utf8 validation.
Regards,
John
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of John Hansen
Sent: Friday, August 06, 2004 2:20 PM
To: 'Hackers'
Subject: [HACKERS] UNICODE character
Josh Berkus <[EMAIL PROTECTED]> writes:
> I think we can work around that. Putting those few parameters in as:
> #SORT_LOCALE = {set at compile time, check SHOW}
> ... would still be an improvement for the *majority* of parameters, which are
> not set at compile time.
Okay, if you can live with
Gaetano Mendola <[EMAIL PROTECTED]> writes:
> $ pg_dump -p 5433 test
> pg_dump: could not parse ACL list ([0:1]={postgres=UC/postgres,=UC/postgres}) for
> object "public" (SCHEMA)
Ugh. This is an unforeseen side effect of Joe's recent changes to make
array_out emit dimension info.
I think the m
Tom,
> Wrong on both counts: it's not really minor (if it were, it would have
> got done) and you will need to touch the code. See the earlier
> discussion. There are several defaults that are presently determined
> at compile time and are not correctly reflected into
> postgresql.conf.sample.
Josh Berkus <[EMAIL PROTECTED]> writes:
> I see this as a really minor change that will greatly improve the
> comprehension of how to modify the .conf file. It's documentation, really,
> and we won't be touching any code.
Wrong on both counts: it's not really minor (if it were, it would hav
On Thu, 2004-08-05 at 22:27, Jonathan M. Gardner wrote:
> A few nights ago, I implemented some of my application logic in PostgreSQL
> via PL/PythonU. I was simply amazed at what I was able to do. My question
> becomes: Why not get rid of the middle layer and move it into the databse
> entirely?
Bruce, etc:
> If you change shared_buffers to 2000, remove the comment and reload, the
> variable is now 2000. If you comment out the variable and reload again,
> it is still 2000, not the default.
And more than one person has been baffled and confused by this, including
several major contribut
On Fri, 6 Aug 2004, Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
Is this the proper item description?
* Remove comments on postgresql.conf variables
It could easily be taken to mean removing this:
#authentication_timeout = 60# 1-600, in seconds
On Fri, 6 Aug 2004, Bruce Momjian wrote:
If you change shared_buffers to 2000, remove the comment and reload, the
variable is now 2000. If you comment out the variable and reload again,
it is still 2000, not the default.
Oh, weird ... and that isn't considered a bug? Definitely wouldn't be the
b
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Is this the proper item description?
> * Remove comments on postgresql.conf variables
It could easily be taken to mean removing this:
#authentication_timeout = 60# 1-600, in seconds
^^^
If you change shared_buffers to 2000, remove the comment and reload, the
variable is now 2000. If you comment out the variable and reload again,
it is still 2000, not the default.
---
Marc G. Fournier wrote:
> On Fri, 6 Aug
G u i d o B a r o s i o wrote:
8.0 || 7.5??
8.0
Regards
Gaetano Mendola
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Tom Lane wrote:
Gaetano Mendola <[EMAIL PROTECTED]> writes:
I did a recovery strictly following the doc instructions, the recovery
succeded but I'm wondering if the following line in the logs is normal
or not.
cp: cannot stat `/home/pitr/0001.history': No such file or directory
Yes, see the p
This message was cancelled from within Mozilla.
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
Hi all,
I have a fresh installation of 8.0devel but I'm not able to
perform any backup using pg_dump:
$ pg_dump -p 5433 test
pg_dump: could not parse ACL list ([0:1]={postgres=UC/postgres,=UC/postgres}) for object
"public" (SCHEMA)
Regards
Gaetano Mendola
---(end of broad
Jonathan,
This is exactly how my company has built a very robust ERP application. See
www.openmfg.com.
All the ERP business logic is in pl/pgsql (20,000+ lines, very high fiber content).
The GUI is the Qt framework for C++, which gives us a client in Linux, Windows, Mac OS
X, and even wireless
On Fri, 6 Aug 2004, Bruce Momjian wrote:
Marc G. Fournier wrote:
Hrmmm, stupid question here, but why not just change hte postgresql.conf
to be those variables that *are* changed from the default, with a simple
comment pointing to the documention for the rest? the benefit of that is
that at lesat
Oh, I see that modification now. Thanks. Sorry I missed it.
---
Joe Conway wrote:
> Bruce Momjian wrote:
> > FYI, I couldn't find anything in the shell pg_config with this path:
> >
> > strncat(otherpath, "/pgxs/s
Marc G. Fournier wrote:
>
> Hrmmm, stupid question here, but why not just change hte postgresql.conf
> to be those variables that *are* changed from the default, with a simple
> comment pointing to the documention for the rest? the benefit of that is
> that at lesat the documentation has fulle
Hrmmm, stupid question here, but why not just change hte postgresql.conf
to be those variables that *are* changed from the default, with a simple
comment pointing to the documention for the rest? the benefit of that is
that at lesat the documentation has fuller descriptions of what the
variabl
Rod Taylor wrote:
> On Tue, 2004-08-03 at 23:36, Christopher Kings-Lynne wrote:
> > I think we need to deny changing column types if a function is using the
> > table type as a return set.
> >
> > test=# create table test (a int4);
> > CREATE TABLE
> > test=# create function test () returns setof
Is this the proper item description?
* Remove comments on postgresql.conf variables
By removing comments we prevent the confusion that commenting a line
returns a modified value to its default, which it does not.
--
VM restarted ...
On Fri, 6 Aug 2004, Mike Rylander wrote:
Seems the NNTP server went wonky again...
TIA!
--
Mike Rylander
[EMAIL PROTECTED]
Indentation is a wonderful form of commentary from
programmer to programmer, but its symbology is
largely wasted on the computer. We don't tell poets
how t
Added to TODO:
* Remove comments on postgresql.conf variables
---
Bruce Momjian wrote:
> Greg Sabino Mullane wrote:
> [ There is text before PGP section. ]
> >
> [ PGP not available, raw data follows ]
> > -BE
Manfred Koizar <[EMAIL PROTECTED]> writes:
> On Fri, 9 Jul 2004 21:29:52 -0400 (EDT), Bruce Momjian
> <[EMAIL PROTECTED]> wrote:
>>
>> Where are we on this, 2x. :-)
> Here:
> Tom Lane wrote:
> Will study these comments later, but it's too late at night here...
I haven't had time to review the o
Seems the NNTP server went wonky again...
TIA!
--
Mike Rylander
[EMAIL PROTECTED]
Indentation is a wonderful form of commentary from
programmer to programmer, but its symbology is
largely wasted on the computer. We don't tell poets
how to format their poetry.
-- Larry Wall
---
On Thu, 1 Jul 2004 22:55:56 -0400, Mike Rylander <[EMAIL PROTECTED]>
wrote:
>I was thinking of purely tablespace-based random_page_cost, as that variable
>is tied to the access time of a particular filesystem.
Strictly speaking we'd also need tablespace-based sequential_page_cost.
Servus
Manfre
[Sorry for the late reply. I'm still struggling to catch up after
vacation ...]
On Fri, 9 Jul 2004 21:29:52 -0400 (EDT), Bruce Momjian
<[EMAIL PROTECTED]> wrote:
>
>Where are we on this, 2x. :-)
Here:
>> Tom Lane wrote:
>> > Will study these comments later, but it's too late at night here...
S
Jonathan M. Gardner wrote:
Thoughts? Comments? Hasn't Oracle done something like this?
Probably this is more suited to -general?
I haven't done anything near this. I wonder how much more painful it is
to debug the application, put it under version control, etc. Personally,
I can't stand editing/d
Tom Lane wrote:
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
I was asked on IRC just why we can't have user=postgres and
group=postgres in the postgresql.conf, and simply when we are run as
root, switch to that user and group.
I should think that running as root up until sometime after we
63 matches
Mail list logo
