2010/7/13 Marko Tiikkaja marko.tiikk...@cs.helsinki.fi:
On 7/12/10 9:34 PM +0300, Tom Lane wrote:
Marko Tiikkajamarko.tiikk...@cs.helsinki.fi 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
2010/7/21 David Fetter da...@fetter.org:
On Sat, Jul 17, 2010 at 01:15:22AM +0900, Hitoshi Harada wrote:
2010/7/17 Marko Tiikkaja marko.tiikk...@cs.helsinki.fi:
On 7/16/10 6:15 PM +0300, Hitoshi Harada wrote:
1. Use MaterialNode instead of adding DtScanNode. Since MaterialNode
is exsiting
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
On Sat, Jul 17, 2010 at 01:15:22AM +0900, Hitoshi Harada wrote:
2010/7/17 Marko Tiikkaja marko.tiikk...@cs.helsinki.fi:
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
On Fri, Jul 16, 2010 at 12:15 PM, Hitoshi Harada umi.tan...@gmail.com wrote:
2010/7/17 Marko Tiikkaja marko.tiikk...@cs.helsinki.fi:
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
On Tue, Jul 20, 2010 at 5:13 PM, Merlin Moncure mmonc...@gmail.com 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
2010/7/13 Marko Tiikkaja marko.tiikk...@cs.helsinki.fi:
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
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
2010/7/17 Marko Tiikkaja marko.tiikk...@cs.helsinki.fi:
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
On 7/16/10 7:15 PM +0300, Hitoshi Harada wrote:
2010/7/17 Marko Tiikkajamarko.tiikk...@cs.helsinki.fi:
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
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
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
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi 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
On 7/12/10 9:34 PM +0300, Tom Lane wrote:
Marko Tiikkajamarko.tiikk...@cs.helsinki.fi 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,
Tom Lane t...@sss.pgh.pa.us 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
Kevin Grittner kevin.gritt...@wicourts.gov 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,
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
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.
Alvaro Herrera alvhe...@commandprompt.com 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
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]
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 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 and
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 this
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]
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
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
-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.
So are
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
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 HEAD if
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 test
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. Once they slow
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)
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
Hi
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
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 SELECT
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
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
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 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
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 so much
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
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
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.
That
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 more
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
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 started out
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 more often.
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. Big
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
a
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
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
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, not
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 grain
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
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 have
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
they
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
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.
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
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.
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, 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
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 be that big
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
to have to
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
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, 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 though.
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
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
Marc G. Fournier wrote:
snip
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 ...
snip
Hmmm... so we do things slightly differently than previously...
This upcoming version could be PG version
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
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
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,
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,
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
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
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
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
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, and
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
that knob to the
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 1003.2 standard). We
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 backend
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
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 does not make
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 recently
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 since
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
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-10646-1),
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
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 we'd
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
---(end of
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 Americanisms in our
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
93 matches
Mail list logo
