For example, in regis.c there are several strings talking about regis
pattern. I had never heard of regis patterns. Turns out they are a
fast regex subset, used AFAICT only by the ispell code. Searching the
web I don't find any other reference to regises (regisen? reges?), so
I think we should
On Sat, 2008-01-12 at 18:46 +, Gregory Stark wrote:
To do something like that the user would have to create a prepared transaction
to save the snapshot. I think that makes sense though since effectively it's
just requiring that the user explicitly do what would otherwise be a hidden
On Thu, 2008-01-17 at 11:56 +0100, Florian G. Pflug wrote:
Tom Lane wrote:
I'm not sure what the most convenient user API would be for an on-demand
hard-read-only mode, but we can't use SET TRANSACTION READ ONLY for it.
It'd have to be some other syntax. Maybe just use a GUC variable
Simon Riggs wrote:
On Sat, 2008-01-12 at 18:46 +, Gregory Stark wrote:
To do something like that the user would have to create a prepared transaction
to save the snapshot. I think that makes sense though since effectively it's
just requiring that the user explicitly do what would otherwise
On Tue, 2008-01-15 at 17:12 +, Gregory Stark wrote:
Wouldn't Segment Exclusion (maybe together with a specialized form of
CLUSTERing) handle that case much better than partitioning? Without the
need to
name all those thousands of partitions and manage them manually.
Firstly we
On Sun, 2008-01-20 at 12:37 +, Heikki Linnakangas wrote:
Simon Riggs wrote:
On Sat, 2008-01-12 at 18:46 +, Gregory Stark wrote:
To do something like that the user would have to create a prepared
transaction
to save the snapshot. I think that makes sense though since
Simon Riggs [EMAIL PROTECTED] writes:
On Sat, 2008-01-12 at 18:46 +, Gregory Stark wrote:
To do something like that the user would have to create a prepared
transaction
to save the snapshot. I think that makes sense though since effectively it's
just requiring that the user explicitly
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
In MySQL I have a function SHA1, which is critical for storing and
authenticating passwords.
It sure would be nice to have this in core. Yeah, there's pgcrypto,
but it's a bit overkill for people who simply want to do a SHA1,
especially
I'm trying to determine if a select statement:
1 - causes execution of a Volatile function
- or -
2 - causes execution of a nextval function (same/similar as #1 above?)
from within tcop / postgres.c ??
Things like QueryIsReadOnly imply that select nextval('some_sequence') are
read-only
Greg Sabino Mullane wrote:
I also realize that SHA1 is not a great solution these days either,
but I'd at least like to see a discussion on moving Postgres to
somewhere between only has md5() and all pg_crypto functions inside
core, even if it only means a handful of SHA functions. Moving
On Sun, Jan 20, 2008 at 05:24:11PM -, Greg Sabino Mullane wrote:
It sure would be nice to have this in core. Yeah, there's pgcrypto,
but it's a bit overkill for people who simply want to do a SHA1,
especially when they see we already have a md5().
md5() was added with the following
Alvaro Herrera wrote:
Greg Sabino Mullane wrote:
I also realize that SHA1 is not a great solution these days either,
but I'd at least like to see a discussion on moving Postgres to
somewhere between only has md5() and all pg_crypto functions inside
core, even if it only means a handful of SHA
Teodor Sigaev [EMAIL PROTECTED] writes:
web I don't find any other reference to regises (regisen? reges?), so
I think we should avoid using the term. How about just changing the
messages to just say regular expression instead?
It's just a combination of regular expression for ispell.
Maybe
Martijn van Oosterhout wrote:
In summary: what would objections be to my writing a sha1() patch?
There wasn't any discussion about it last time. It does seem a bit
wierd to support one but not the other. It's also interesting to note
that the implementation in the backed is commented with:
Greg Sabino Mullane [EMAIL PROTECTED] writes:
In summary: what would objections be to my writing a sha1() patch?
Mainly that no one else is dissatisfied with the current split between
core and pgcrypto.
The only reason md5() is in core is to support encryption of passwords
in pg_shadow. There
Is the bgwriter_lru_multiplier parameter a limit on the number to scan
or to write? GUC and docs seem to contradict one another. GUC says
#: utils/misc/guc.c:1834
#, fuzzy
msgid Background writer multiplier on average buffers to scan per round.
The docs say
Unless limited by
On Sun, 2008-01-20 at 15:11 +, Gregory Stark wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Sat, 2008-01-12 at 18:46 +, Gregory Stark wrote:
To do something like that the user would have to create a prepared
transaction
to save the snapshot. I think that makes sense though
Alvaro Herrera [EMAIL PROTECTED] writes:
Is the bgwriter_lru_multiplier parameter a limit on the number to scan
or to write? GUC and docs seem to contradict one another. GUC says
#: utils/misc/guc.c:1834
#, fuzzy
msgid Background writer multiplier on average buffers to scan per round.
On Sun, Jan 20, 2008 at 01:42:21PM -0500, Tom Lane wrote:
Greg Sabino Mullane [EMAIL PROTECTED] writes:
In summary: what would objections be to my writing a sha1() patch?
Mainly that no one else is dissatisfied with the current split
between core and pgcrypto.
The only reason md5() is
Hi everyone,
I believe that there is a small bug in src/port/rint.c when the input
parameter has a fractional part of 0.5 which is demonstrated by the
attached program. It appears that the PG version of rint() rounds in the
wrong direction with respect to glibc.
[EMAIL PROTECTED]:~$ ./test
On Sun, 20 Jan 2008, Alvaro Herrera wrote:
Is the bgwriter_lru_multiplier parameter a limit on the number to scan
or to write? GUC and docs seem to contradict one another.
It adjusts the target for how many clean buffers it wants to either find
or create. This always increases the number
Mark Cave-Ayland [EMAIL PROTECTED] writes:
I believe that there is a small bug in src/port/rint.c when the input
parameter has a fractional part of 0.5 which is demonstrated by the
attached program. It appears that the PG version of rint() rounds in the
wrong direction with respect to glibc.
Maybe the right phrase to use is ispell regular expression. In any
case we need to document what the limitations are compared to regular
regular expressions (ahem). Do you know offhand what the rules are?
There is a fallback to regex if expression isn't supported by regis (see call
of
Teodor Sigaev [EMAIL PROTECTED] writes:
There is a fallback to regex if expression isn't supported by regis (see
call
of RS_isRegis() in spell.c).
Oh. So in that case, the messages Alvaro is worried about
ereport(ERROR,
Tom Lane wrote:
Mark Cave-Ayland [EMAIL PROTECTED] writes:
I believe that there is a small bug in src/port/rint.c when the input
parameter has a fractional part of 0.5 which is demonstrated by the
attached program. It appears that the PG version of rint() rounds in the
wrong direction with
Magnus Hagander [EMAIL PROTECTED] writes:
Tom Lane wrote:
Considering that probably every modern platform has rint(), I doubt
it's worth spending time on our stopgap version to try to make it
fully IEEE-compliant ...
Except win32.
Hasn't it got something equivalent? This is IEEE-required
Greg Smith [EMAIL PROTECTED] writes:
There is nothing incorrect here, it's just not as clear as it could be.
Here's a V2 that tries to clear that up:
Unless limited by varnamebgwriter_lru_maxpages/, the number of dirty
buffers written in each round is based on the number of new buffers that
Mark Cave-Ayland [EMAIL PROTECTED] writes:
The big question is, of course, how much difference does this make?
Probably not a lot. If we can find an IEEE-compliant rounding function
on Windows, I'd be happy to see rint() fixed to call it; beyond that
I think it's not worth troubling with.
Teodor Sigaev wrote:
aren't user-facing errors at all, and should be demoted to elog's,
correct?
elog(ERROR, invalid regis pattern: \%s\, str);
Hmm. If regis detects an error in expression then it will be an error for
regex library too. At least, it was supposed to be.
And
Alvaro Herrera [EMAIL PROTECTED] writes:
Teodor Sigaev wrote:
Hmm. If regis detects an error in expression then it will be an error for
regex library too. At least, it was supposed to be.
And those that are not, probably are not what the user intends anyway,
with the pattern language being
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
Tom Lane wrote:
Considering that probably every modern platform has rint(), I doubt
it's worth spending time on our stopgap version to try to make it
fully IEEE-compliant ...
Except win32.
Hasn't it got something equivalent? This
Hello
The different-numbers-of-arguments bit is what I'm objecting to.
Just register the function as foo(ANY), foo(ANY,ANY), foo(ANY,ANY,ANY),
etc, and you're done without breaking anything else.
I found simple solution, it uses ANY, but number of necessary ANY
arguments is generated
aren't user-facing errors at all, and should be demoted to elog's,
correct?
elog(ERROR, invalid regis pattern: \%s\, str);
Hmm. If regis detects an error in expression then it will be an error for regex
library too. At least, it was supposed to be.
--
Teodor Sigaev
On Sun, 2008-01-20 at 16:47 -0500, Tom Lane wrote:
Your proposed fix wouldn't make it act the same as glibc, only move the
differences around. I believe glibc's default behavior for the
ambiguous cases is round to nearest even number. You propose
replacing round towards zero, which is what
This thread made me try this example. Note that there's a WARNING in the spot
where I pressed tab.
alvherre=# create or replace function foo (out pg_class) language plpgsql as $$
declare i pg_class%rowtype; begin for i in select * from pg_class loop return
next; end loop; end; $$;
ERROR:
Alvaro Herrera [EMAIL PROTECTED] writes:
alvherre=# set lc_messWARNING: problem in alloc set PL/PgSQL function
context: detected write past chunk end in block 0xb541d0, chunk 0xb562c0
ages to 'C';
WARNING: problem in alloc set PL/PgSQL function context: detected write past
chunk en
d in
Folks,
8.3's psql is ponderously unhelpful when getting the type description
of an enum, so I'd like to propose a new column in the \dT output
which can contain those values in an array format. Yes, I know it
looks like a new feature, but it's really a bug fix.
Cheers,
David.
--
David Fetter
On Sun, 20 Jan 2008, Tom Lane wrote:
I think the main problem is the qualifying clause up front in a place
of prominence. Here's a V3 try
That one looks good to me. These are small details but better to get it
right now.
--
* Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com
I wrote:
It looks to me like RS_isRegis() needs to be tightened up a bit anyway:
it will accept ^foo which is valid regex but not valid regis, leading
to an error being thrown which is not what we want.
I experimented with this and verified that the error could be reached
with a hacked-up
Alvaro Herrera [EMAIL PROTECTED] writes:
Additionally, I would like to apply the attached patch. Are there
objections?
So far I think you only applied one half of that?
regards, tom lane
---(end of broadcast)---
TIP 1:
Greg Smith [EMAIL PROTECTED] writes:
On Sun, 20 Jan 2008, Tom Lane wrote:
I think the main problem is the qualifying clause up front in a place
of prominence. Here's a V3 try
That one looks good to me. These are small details but better to get it
right now.
OK, committed. Back to
David Fetter [EMAIL PROTECTED] writes:
8.3's psql is ponderously unhelpful when getting the type description
of an enum, so I'd like to propose a new column in the \dT output
which can contain those values in an array format.
... and how wide is your screen, again?
I read that Perl 5.10 is about to hit Fedora rawhide. Anyone know if
it will work with plperl and/or DBD::Pg? If there are fixes needed
in plperl, it'd sure be nice if they were in 8.3 ...
regards, tom lane
---(end of
Kurt Roeckx wrote:
Hi,
Has anyone tried to use the huge tlb support of the Linux 2.6 kernel?
If you compile the kernel with support for it (CONFIG_HUGETLBFS), you
can call shmget() with a SHM_HUGETLB parameter so that it will use
larger pages.
Has anyone tried to use it? Is it worth trying to
Hi Simon, and Dave,Magnus.
About pg_standby, a link option cause a problem in windows(XP and 2k,2k3).
It is because the call of mklink is needed. Then, they are the new programs of
VISTA and 2008. It is CreateSymbolicLink of API of kernel32.lib is equipped
with mklink.
* David Fetter:
Is there any country with laws so benighted that they restrict secure
hashing algorithms? Right now, there's a contest between SHA1 and
MD5 as to which one gets broken first, and SHA1 appears to be in the
lead. SHAn for n1 could preempt the awfulness of losing this race.
On Mon, 2008-01-21 at 15:36 +0900, Hiroshi Saito wrote:
Hi Simon, and Dave,Magnus.
About pg_standby, a link option cause a problem in windows(XP and 2k,2k3).
It is because the call of mklink is needed. Then, they are the new programs
of
VISTA and 2008. It is CreateSymbolicLink of API of
47 matches
Mail list logo
