2010/7/13 Marko Tiikkaja :
> On 7/12/10 9:34 PM +0300, Tom Lane wrote:
>>
>> Marko Tiikkaja writes:
>>>
>>> ... So what I'm now thinking of is making the planner plan that as a
>>> single
>>> Query, and make the planner expand it into multiple PlannedStmts if
>>> necessary. This would break the e
On 8/3/2010 7:30 PM, Hitoshi Harada wrote:
As hackers say, the first to try should be Marko's first design that
use the list of tuplestore and DTScanNode. So if he has solid image to
reach there, we can wait for him to complete his first compilable
version. Then let's take it back and forth. Is i
2010/7/21 David Fetter :
> On Sat, Jul 17, 2010 at 01:15:22AM +0900, Hitoshi Harada wrote:
>> 2010/7/17 Marko Tiikkaja :
>> > On 7/16/10 6:15 PM +0300, Hitoshi Harada wrote:
>> >> 1. Use MaterialNode instead of adding DtScanNode. Since MaterialNode
>> >> is exsiting one that work with single tuples
On Tue, Jul 20, 2010 at 5:13 PM, Merlin Moncure wrote:
2. Use temp table instead of tuplestore list. Since we agreed we need
to execute each plan one by one starting and shutting down executor,
it now looks very simple strategy.
>>>
>>> I didn't look at this because I thought using
On Fri, Jul 16, 2010 at 12:15 PM, Hitoshi Harada wrote:
> 2010/7/17 Marko Tiikkaja :
>> On 7/16/10 6:15 PM +0300, Hitoshi Harada wrote:
>>>
>>> 1. Use MaterialNode instead of adding DtScanNode. Since MaterialNode
>>> is exsiting one that work with single tuplestore, it might be sane to
>>> modify
On Sat, Jul 17, 2010 at 01:15:22AM +0900, Hitoshi Harada wrote:
> 2010/7/17 Marko Tiikkaja :
> > On 7/16/10 6:15 PM +0300, Hitoshi Harada wrote:
> >>
> >> 1. Use MaterialNode instead of adding DtScanNode. Since MaterialNode
> >> is exsiting one that work with single tuplestore, it might be sane to
On 7/16/10 7:15 PM +0300, Hitoshi Harada wrote:
2010/7/17 Marko Tiikkaja:
I thought about this, but I don't necessarily like the idea of overloading
executor nodes.
Neither do I have good shape for this solution. Maybe it's not good
idea. But my concern is adding DtScanNode, which looks simila
2010/7/17 Marko Tiikkaja :
> On 7/16/10 6:15 PM +0300, Hitoshi Harada wrote:
>>
>> 1. Use MaterialNode instead of adding DtScanNode. Since MaterialNode
>> is exsiting one that work with single tuplestore, it might be sane to
>> modify this so that it accepts tuplestore from Query instead of its
>>
On 7/16/10 6:15 PM +0300, Hitoshi Harada wrote:
Sorry it's not relevant to the topic you post but ..
Relevant enough :-)
.. it seems you're
going to add new executor node called DtScanNode and let it hold
tuplestore passed by the Query indicated by index number. However, I
suppose there are o
2010/7/13 Marko Tiikkaja :
> Hi,
>
>
> I've been working on writeable CTEs during the last couple of months, but
> right now it looks like I'm going to miss the first commit fest for 9.1. I
> was trying to make it work by expanding all wCTEs to their own Queries
> during the rewrite stage (a very
On 7/12/10 9:34 PM +0300, Tom Lane wrote:
Marko Tiikkaja writes:
... So what I'm now thinking of is making the planner plan that as a single
Query, and make the planner expand it into multiple PlannedStmts if
necessary. This would break the existing planner hooks, but I don't
think that's a hu
Marko Tiikkaja writes:
> ... So what I'm now thinking of is making the planner plan that as a single
> Query, and make the planner expand it into multiple PlannedStmts if
> necessary. This would break the existing planner hooks, but I don't
> think that's a huge problem. Does anyone see any o
On 7/12/10 9:07 PM +0300, I wrote:
Consider:
WITH t AS (SELECT 1),
t2 AS (SELECT * FROM t2)
VALUES (true);
That should of course have been SELECT * FROM t, not t2.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your s
Hi,
I've been working on writeable CTEs during the last couple of months,
but right now it looks like I'm going to miss the first commit fest for
9.1. I was trying to make it work by expanding all wCTEs to their own
Queries during the rewrite stage (a very crude patch trying to do that
for
"Kevin Grittner" writes:
> ...
> We were able to get to much cleaner code by rewriting the parser to
> have a "dumb" phase to get the overall structure into an AST, and then
> use a tree-walker phase to do all the lookups and type resolution
> after we had the rough structure, writing another AST
Tom Lane wrote:
> One problem that wasn't obvious when I started is that if you are
> trying to use a reentrant lexer, Bison insists on including its
> YYSTYPE union in the call signature of the lexer. Of course,
> YYSTYPE means different things to the core grammar and plpgsql's
> grammar. I
Alvaro Herrera writes:
> Tom Lane wrote:
>> ... I spent a fair amount of time trying to work around that
>> by eliminating uses of "yytext" in plpgsql, and mostly succeeded, but
>> there are still some left. (Some of the remaining regression failures are
>> error messages that point at the wrong
Tom Lane wrote:
> Another pretty serious issue is that the current plpgsql lexer treats
> various sorts of qualified names as single tokens. I had thought this
> could be worked around in the interface layer by doing more lookahead.
> You can do that, and it mostly works, but it's mighty tedious.
I've spent the past several days working on the project I suggested here:
http://archives.postgresql.org/message-id/18653.1239741...@sss.pgh.pa.us
of getting rid of plpgsql's private lexer and having it use the core
lexer instead. I've run out of time for that and need to go focus on
commitfest re
The patch set of SE-PostgreSQL and related stuff were updated (r1467).
[1/5]
http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1467.patch
[2/5]
http://sepgsql.googlecode.com/files/sepostgresql-utils-8.4devel-3-r1467.patch
[3/5]
http://sepgsql.googlecode.com/files/sepostgresql
Robert Treat wrote:
On Friday 16 January 2009 19:16:42 Simon Riggs wrote:
Bruce asked for 2 more weeks to get patches into shape for commit.
Current patch v8e is attached here. Ready for commit? Up to you.
My overall opinion is that it's in very good shape. Worth the community
including it
On Tue, 2009-01-20 at 18:08 -0500, Robert Treat wrote:
> > The patch could benefit further from input from other various hackers,
> > what couldn't? It's time to put this in a shared repository (of some
> > kind) and make further changes to it in a controlled manner.
> >
>
> Yep. I've now got th
On Friday 16 January 2009 19:16:42 Simon Riggs wrote:
> Bruce asked for 2 more weeks to get patches into shape for commit.
>
> Current patch v8e is attached here. Ready for commit? Up to you.
>
> My overall opinion is that it's in very good shape. Worth the community
> including it in this release
I also think it is a good idea to summarize current status of
SE-PostgreSQL, as Simon Riggs doing on his works.
The current revision of SE-PostgreSQL is 1425, available here:
[1/5]
http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1425.patch
[2/5]
http://sepgsql.googlecode.
Joshua D. Drake wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Thu, 29 Nov 2007 14:01:11 -0800
> Neil Conway <[EMAIL PROTECTED]> wrote:
>
> > On Thu, 2007-11-29 at 11:26 -0500, Bruce Momjian wrote:
> > > I expect these cleanups to continue for at least another week or
> > > two.
"Andreas 'ads' Scherbaum" <[EMAIL PROTECTED]> writes:
> i would also like to test another Beta, if we do something about this
> problem:
>
> http://archives.postgresql.org/pgsql-hackers/2007-11/msg00960.php
That's already done, it would be in the next beta. You could check out a copy
from CVS HEA
On Fri, 30 Nov 2007 11:26:35 +1100 Brendan Jurd wrote:
> On Nov 30, 2007 11:10 AM, Andreas 'ads' Scherbaum <[EMAIL PROTECTED]> wrote:
> > i would also like to test another Beta, if we do something about this
> > problem:
> >
> > http://archives.postgresql.org/pgsql-hackers/2007-11/msg00960.php
>
On Nov 30, 2007 11:10 AM, Andreas 'ads' Scherbaum <[EMAIL PROTECTED]> wrote:
> i would also like to test another Beta, if we do something about this
> problem:
>
> http://archives.postgresql.org/pgsql-hackers/2007-11/msg00960.php
Hi Andreas,
Tom's already committed the quote_literal(anyelement) f
Hello,
On Thu, 29 Nov 2007 17:21:09 -0500 Tom Lane wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > So are there no plans for an additional beta?
>
> Yes, there are, but not till we do something about
> http://archives.postgresql.org/pgsql-hackers/2007-11/msg01302.php
i would also like to
Neil Conway <[EMAIL PROTECTED]> writes:
> So are there no plans for an additional beta?
Yes, there are, but not till we do something about
http://archives.postgresql.org/pgsql-hackers/2007-11/msg01302.php
regards, tom lane
---(end of broadcast)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 29 Nov 2007 14:01:11 -0800
Neil Conway <[EMAIL PROTECTED]> wrote:
> On Thu, 2007-11-29 at 11:26 -0500, Bruce Momjian wrote:
> > I expect these cleanups to continue for at least another week or
> > two. Once they slow we will schedule RC1.
>
>
On Thu, 2007-11-29 at 11:26 -0500, Bruce Momjian wrote:
> I expect these cleanups to continue for at least another week or two.
> Once they slow we will schedule RC1.
So are there no plans for an additional beta? Given the recent addition
of changes like
http://archives.postgresql.org/pgsql-comm
I wanted to give everyone an overview of where we are for 8.3. We have
addressed almost every major issue for 8.3 but we are getting a steady
stream of minor cleanups. These cleanups are vital to keep the quality
of Postgres at a high level. It allows us to make major changes in
every release bu
Christopher Kings-Lynne wrote:
> > We can have a major feature deadline, then a minor feature deadline. I
> > particularly liked the idea of 1 July as the major feature deadline,
> > then 14 July as major-feature-tweak deadline. That funnels things better
> > to cater for the manpower available.
>
On Thu, 15 Jul 2004, Christopher Kings-Lynne wrote:
We can have a major feature deadline, then a minor feature deadline. I
particularly liked the idea of 1 July as the major feature deadline,
then 14 July as major-feature-tweak deadline. That funnels things better
to cater for the manpower availabl
We can have a major feature deadline, then a minor feature deadline. I
particularly liked the idea of 1 July as the major feature deadline,
then 14 July as major-feature-tweak deadline. That funnels things better
to cater for the manpower available.
That being said, your PITR patch still hasn't bee
On Wed, 2004-07-14 at 21:02, Bruce Momjian wrote:
> Marc G. Fournier wrote:
> > The big problem that I see with how this feature freeze/beta/release has
> > gone down is that we have *alot* of big items that are/were being worked
> > on (ARC, BGWriter, auto_vacuum, PITR, Nested Xacts), and only s
On Tue, 2004-07-13 at 23:03, Marc G. Fournier wrote:
> As a community, I don't think we should be 'supporting' anything older
> then the last STABLE ...
>
I agree, but that message isn't clearly stated anywhere. The lists are
full of people running very old releases - and everybody keeps having
Marc G. Fournier wrote:
> The big problem that I see with how this feature freeze/beta/release has
> gone down is that we have *alot* of big items that are/were being worked
> on (ARC, BGWriter, auto_vacuum, PITR, Nested Xacts), and only so much man
> power at the reviewer stage ... we *should*
On 7/14/2004 1:13 PM, Bruce Momjian wrote:
What are you talking about? Are you suggesting Fujitsu's features are
getting more attendtion than ARC for some political reason? You think
nested transactions and tablespaces are just press release features?
All those features are being developed by th
On Wed, 14 Jul 2004, Bruce Momjian wrote:
What are you talking about? Are you suggesting Fujitsu's features are
getting more attendtion than ARC for some political reason? You think
nested transactions and tablespaces are just press release features?
All those features are being developed by the
Jan Wieck wrote:
> On 7/13/2004 10:23 PM, Christopher Kings-Lynne wrote:
>
> >> I was thinking of something much simpler where Jan would create an ARC
> >> patch against 7.4.X and have it either in /contrib for 7.4.X or on our
> >> ftp servers, or on a web site. I could create a mechanism so SELE
On 7/13/2004 10:23 PM, Christopher Kings-Lynne wrote:
I was thinking of something much simpler where Jan would create an ARC
patch against 7.4.X and have it either in /contrib for 7.4.X or on our
ftp servers, or on a web site. I could create a mechanism so SELECT
version() would display Jan's add-
Marc G. Fournier wrote:
As Jan points out, its the 'small features that are done' that we've
been griping about having to wait for, not the big ones which we know
aren't done ...
Hmmm... so we do things slightly differently than previously...
This upcoming version could be PG version 8.0,
We co
I was thinking of something much simpler where Jan would create an ARC
patch against 7.4.X and have it either in /contrib for 7.4.X or on our
ftp servers, or on a web site. I could create a mechanism so SELECT
version() would display Jan's add-on.
I think you guys just need to learn to become comf
God, we still have clients using 7.2 servers, cause they've had no
reason yet to upgrade to the latest ... "it works, why upgrade?" is
generally the opinion ...
Because there's shocking failure-to-restart bugs in 7.2...and if you
upgrade to 7.4 you're forced to get new features as well.
Chris
-
On Tue, 2004-07-13 at 20:49, Marc G. Fournier wrote:
> On Tue, 13 Jul 2004, Tom Lane wrote:
>
> > We could certainly do something along that line if we had a few people
> > willing to be "gatekeepers". We'd have to work harder at making the
> > release generation process open and documented tho
> However, looking at how the Linux community handles it, I think we can
> borrow a lot of concepts from them.
I was thinking quite the opposite. The Linux community doesn't exactly
have a great track-record for their stable releases.
The thoughts behind the process might be good, but do we have
On Tue, 13 Jul 2004, Bruce Momjian wrote:
The nice thing about doing something lke that is those small features
would get a degree of testing happening in a live environment ...
Of course that last sentence is the downside too --- people don't want
to have to retest their setups after a minor relea
Marc G. Fournier wrote:
> On Tue, 13 Jul 2004, Bruce Momjian wrote:
>
> >> The nice thing about doing something lke that is those small features
> >> would get a degree of testing happening in a live environment ...
> >
> > Of course that last sentence is the downside too --- people don't want
> >
On Tue, 2004-07-13 at 13:03 -0400, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Jan Wieck wrote:
> >> I think in the future we have to force all large features, those that
> >> probably need more than 6 months of development time, to be properly
> >> #ifdef'd. Then it wouldn't
On Tue, 13 Jul 2004, Bruce Momjian wrote:
We have always recommended upgrading to the most recent minor release,
at least as a project policy for support. Also, the upgrade is only
stop/install/restart so it is quite easy to do, and folks like the fact
they don't have to test for new functional
Marc G. Fournier wrote:
> On Tue, 13 Jul 2004, Bruce Momjian wrote:
>
> > I was thinking of something much simpler where Jan would create an ARC
> > patch against 7.4.X and have it either in /contrib for 7.4.X or on our
> > ftp servers, or on a web site. I could create a mechanism so SELECT
>
On Tue, 13 Jul 2004, Lamar Owen wrote:
But Tom's assertion is true. We have enough trouble getting patches
rolled out; adding parallel branches is just begging for trouble, due to
our relatively small resource size. Although, we probably have enough
developers at this point to make it happen.
On Tue, 13 Jul 2004, Bruce Momjian wrote:
I was thinking of something much simpler where Jan would create an ARC
patch against 7.4.X and have it either in /contrib for 7.4.X or on our
ftp servers, or on a web site. I could create a mechanism so SELECT
version() would display Jan's add-on.
I thi
On Wed, 14 Jul 2004, Peter Eisentraut wrote:
Marc G. Fournier wrote:
Nobody would be required to upgrade to a new minor release either ...
nobody is *require* to upgrade to any release, for that matter ...
Most people don't have the time to investigate release notes, release
policy details, etc. W
On Tue, 13 Jul 2004, Tom Lane wrote:
We could certainly do something along that line if we had a few people
willing to be "gatekeepers". We'd have to work harder at making the
release generation process open and documented though. Right now there
are plenty of steps that only you, Bruce, or La
Marc G. Fournier wrote:
> On Tue, 13 Jul 2004, Bruce Momjian wrote:
>
> > We have always recommended upgrading to the most recent minor release,
> > at least as a project policy for support. Also, the upgrade is only
> > stop/install/restart so it is quite easy to do, and folks like the fact
>
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> On Tue, 13 Jul 2004, Lamar Owen wrote:
>> But Tom's assertion is true. We have enough trouble getting patches
>> rolled out; adding parallel branches is just begging for trouble, due to
>> our relatively small resource size. Although, we probably
Marc G. Fournier wrote:
> Nobody would be required to upgrade to a new minor release either ...
> nobody is *require* to upgrade to any release, for that matter ...
Most people don't have the time to investigate release notes, release
policy details, etc. When there are bug fix updates, you use
On Tuesday 13 July 2004 08:52 am, Jan Wieck wrote:
>
> I think in the future we have to force all large features, those that
> probably need more than 6 months of development time, to be properly
> #ifdef'd. Then it wouldn't be that big of a deal to release more often.
>
>
Take my opinion with a g
On Tuesday 13 July 2004 17:12, Marc G. Fournier wrote:
> ... there is alot of stuff that doesn't require a reload of the database
> (or initdb) that could very easily be backpatched ...
> As Jan points out, its the 'small features that are done' that we've been
> griping about having to wait for,
Marc G. Fournier wrote:
>
> Note that I'm all for a long (2 year? or even 'indefinite') development
> cycle for a major release if we continue on with what has been happening
> more often lately, where stuff is back patched to the last stable release
> ... there is alot of stuff that doesn't re
Note that I'm all for a long (2 year? or even 'indefinite') development
cycle for a major release if we continue on with what has been happening
more often lately, where stuff is back patched to the last stable release
... there is alot of stuff that doesn't require a reload of the database
(or
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Of course this all ties into the pain of having to dump/reload large
> >> databases, and maybe if we had working pg_upgrade the adoption rate
> >> would be faster, but I'm not at all sure of that. We're playing in
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Of course this all ties into the pain of having to dump/reload large
>> databases, and maybe if we had working pg_upgrade the adoption rate
>> would be faster, but I'm not at all sure of that. We're playing in
>> a different league now
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Jan Wieck wrote:
> >> I think in the future we have to force all large features, those that
> >> probably need more than 6 months of development time, to be properly
> >> #ifdef'd. Then it wouldn't be that big of a deal to release mo
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Jan Wieck wrote:
>> I think in the future we have to force all large features, those that
>> probably need more than 6 months of development time, to be properly
>> #ifdef'd. Then it wouldn't be that big of a deal to release more often.
> Alvaro starte
On 7/10/2004 11:02 PM, Bruce Momjian wrote:
If you get full control of PostgreSQL, you can dictate what will happen.
Until then, I will follow the community consensus, which may or may not
match your opinion.
Marc isn't the only one who didn't like waiting for more features going
into 7.5 two mont
Jan Wieck wrote:
> On 7/10/2004 11:02 PM, Bruce Momjian wrote:
>
> > If you get full control of PostgreSQL, you can dictate what will happen.
> > Until then, I will follow the community consensus, which may or may not
> > match your opinion.
>
> Marc isn't the only one who didn't like waiting for
Justin Clift wrote:
Bruce Momjian wrote:
If you get full control of PostgreSQL, you can dictate what will happen.
Until then, I will follow the community consensus, which may or may not
match your opinion.
Um, let's take the time to get the features in, otherwise we'll be
waiting another year (ro
Bruce Momjian wrote:
If you get full control of PostgreSQL, you can dictate what will happen.
Until then, I will follow the community consensus, which may or may not
match your opinion.
Um, let's take the time to get the features in, otherwise we'll be
waiting another year (roughly) to get PITR an
If you get full control of PostgreSQL, you can dictate what will happen.
Until then, I will follow the community consensus, which may or may not
match your opinion.
---
Marc G. Fournier wrote:
> On Sat, 10 Jul 2004, Bruce Mo
On Sat, 10 Jul 2004, Bruce Momjian wrote:
My point is that it isn't the patch submitters we are waiting on
anymore. It is the backlog of patches that need review/adjustment.
"Of course, many of the patches I kept need some adjustment to get applied
..." ... to me, that indicates that even after r
My point is that it isn't the patch submitters we are waiting on
anymore. It is the backlog of patches that need review/adjustment.
---
Marc G. Fournier wrote:
> On Sat, 10 Jul 2004, Bruce Momjian wrote:
>
> > I am still g
On Sat, 10 Jul 2004, Bruce Momjian wrote:
I am still going through my mailbox, trying to address all the open
patches so we can move toward beta. Of course, many of the patches I
kept need some adjustment to get applied (e.g. configuration file
location) so it is slow going.
However, we still have
I am still going through my mailbox, trying to address all the open
patches so we can move toward beta. Of course, many of the patches I
kept need some adjustment to get applied (e.g. configuration file
location) so it is slow going.
However, we still have PITR unapplied, autovacuum unapplied, and
I am still going through my mailbox, trying to address all the open
patches so we can move toward beta. Of course, many of the patches I
kept need some adjustment to get applied (e.g. configuration file
location) so it is slow going.
However, we still have PITR unapplied, autovacuum unapplied, an
Tatsuo Ishii writes:
> > UTF-8 seems to be the most popular, but even XML standard requires all
> > compliant implementations to deal with at least both UTF-8 and UTF-16.
>
> I don't think PostgreSQL is going to natively support UTF-16.
At FOSDEM it was claimed that Windows natively uses UCS-2, a
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> code is concerned: the regex library actually offers three regex
>> flavors, "advanced", "extended", and "basic", where "extended" matches
>> what we had before ("extended" and "basic" correspond to different
>> levels of the POSIX
Tom Lane writes:
> code is concerned: the regex library actually offers three regex
> flavors, "advanced", "extended", and "basic", where "extended" matches
> what we had before ("extended" and "basic" correspond to different
> levels of the POSIX 1003.2 standard). We just need a way to expose
>
Tatsuo Ishii kirjutas R, 07.02.2003 kell 04:03:
> > UTF-8 seems to be the most popular, but even XML standard requires all
> > compliant implementations to deal with at least both UTF-8 and UTF-16.
>
> I don't think PostgreSQL is going to natively support UTF-16.
By natively, do you mean "as bac
On Fri, 7 Feb 2003 00:49, Hannu Krosing wrote:
> Tatsuo Ishii kirjutas N, 06.02.2003 kell 17:05:
> > > Perhaps we should not call the encoding UNICODE but UTF8 (which it
> > > really is). UNICODE is a character set which has half a dozen official
> > > encodings and calling one of them "UNICODE" do
> > Right. Also we perhaps should call LATIN1 or ISO-8859-1 more precisely
> > way since ISO-8859-1 can be encoded in either 7 bit or 8 bit(we use
> > this). I don't know what it is called though.
>
> I don't think that calling 8-bit ISO-8859-1 ISO-8859-1 can confuse
> anybody, but UCS-2 (ISO-1064
Tatsuo Ishii kirjutas N, 06.02.2003 kell 17:05:
> > Perhaps we should not call the encoding UNICODE but UTF8 (which it
> > really is). UNICODE is a character set which has half a dozen official
> > encodings and calling one of them "UNICODE" does not make things very
> > clear.
>
> Right. Also we
> Perhaps we should not call the encoding UNICODE but UTF8 (which it
> really is). UNICODE is a character set which has half a dozen official
> encodings and calling one of them "UNICODE" does not make things very
> clear.
Right. Also we perhaps should call LATIN1 or ISO-8859-1 more precisely
way
On Thu, 2003-02-06 at 13:25, Tatsuo Ishii wrote:
> > I have just committed the latest version of Henry Spencer's regex
> > package (lifted from Tcl 8.4.1) into CVS HEAD. This code is natively
> > able to handle wide characters efficiently, and so it avoids the
> > multibyte performance problems re
> I have just committed the latest version of Henry Spencer's regex
> package (lifted from Tcl 8.4.1) into CVS HEAD. This code is natively
> able to handle wide characters efficiently, and so it avoids the
> multibyte performance problems recently exhibited by Wade Klaver.
> I have not done extens
Christopher Kings-Lynne kirjutas N, 06.02.2003 kell 03:56:
> > > set regex_flavor = advanced
> > > set regex_flavor = extended
> > > set regex_flavor = basic
> > [snip]
> > > Any suggestions about the name of the parameter?
> >
> > Actually I think 'regex_flavor' sounds fine.
>
> Not more A
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
>> You want regex_flavour? ;-)
> Hehe - yeah I don't really care. I have to use 'color' often enough
> accessing 100% of the world's programming APIs...
> How about regex_type, regex_mode, regex_option, etc.? ;)
Well, I used "flavor" in my p
> "Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> >> Actually I think 'regex_flavor' sounds fine.
>
> > Not more Americanisms in our config files!! :P
>
> You want regex_flavour? ;-)
Hehe - yeah I don't really care. I have to use 'color' often enough
accessing 100% of the world's programm
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
>> Actually I think 'regex_flavor' sounds fine.
> Not more Americanisms in our config files!! :P
You want regex_flavour? ;-)
regards, tom lane
---(end of broadcast)---
T
> > set regex_flavor = advanced
> > set regex_flavor = extended
> > set regex_flavor = basic
> [snip]
> > Any suggestions about the name of the parameter?
>
> Actually I think 'regex_flavor' sounds fine.
Not more Americanisms in our config files!! :P
Chris
-
On Wed, 5 Feb 2003, Tom Lane wrote:
> 1. There are a couple of minor incompatibilities between the "advanced"
> regex syntax implemented by this package and the syntax handled by our
> old code; in particular, backslash is now a special character within
> bracket expressions. It seems to me that
I have just committed the latest version of Henry Spencer's regex
package (lifted from Tcl 8.4.1) into CVS HEAD. This code is natively
able to handle wide characters efficiently, and so it avoids the
multibyte performance problems recently exhibited by Wade Klaver.
I have not done extensive perfor
With my pg_hba.conf changes done, I am now focusing in the next few days
on clearing out my email/patch application backlog.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blyt
96 matches
Mail list logo
