On Jul 13, 2008, at 10:19, Tom Lane wrote:
You might try running the
opr_sanity regression test on this module to see if it finds any
other silliness. (Procedure: insert the citext definition script
into the serial_schedule list just ahead of opr_sanity, run tests,
make sure you understand the
On Jul 13, 2008, at 10:31, Tom Lane wrote:
Grr. Kind of defeats the purpose. Is there no infrastructure for
testing multibyte functionality?
There's some stuff under src/test/locale and src/test/mb, though it
doesn't get exercised regularly. The contrib tests are a particularly
bad place for
On Jul 12, 2008, at 14:57, Tom Lane wrote:
4. A lot of the later test cases are equally uselessly testing whether
piggybacking over text functions works. The odds of ever finding
anything with those tests are not distinguishable from zero (unless
the
underlying text function is busted, which
On Mon, 14 Jul 2008, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
Isn't the vacuum_delay_point() good enough?
But that's in the outer loop ... I mean here:
You'd need one heckuva lot of lexemes in a tsvector to make that
Tom, I like the 'heckuva' word (in
-- Forwarded message --
From: Jerry Stuckle [EMAIL PROTECTED]
Date: Jul 13, 10:29 pm
Subject: Proposal - UUID data type
To: comp.databases.mysql
Kless wrote:
On Jul 13, 9:37 pm, Jerry Stuckle [EMAIL PROTECTED] wrote:
Rather, I would think you should propose the UUID data
On Mon, Jul 14, 2008 at 01:04:33AM -0700, Kless wrote:
I am not in favor of adding more database-specific types to ANY
database
- and I think PostGres doing it was a mistake.
So you think that adding full text indexing, gist/gin indexes, text,
geometric types should have waited until the SQL
[EMAIL PROTECTED] [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
X-Sender: [EMAIL PROTECTED]
Received: from
On Mon, 14 Jul 2008, Rudolf Lippan wrote:
[EMAIL PROTECTED] [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
X-Sender: [EMAIL
David E. Wheeler wrote:
(If we get to having per-database collations in 8.4 then integrating a
test with a non-default collation would get a lot easier, of course;
but for the moment I'm afraid you've got to work with what's there.)
Could I supply two comparison files, one for Mac OS X with
Andrew Dunstan wrote:
Some time ago I raised the question of doing locale- and encoding-aware
regression tests, and IIRC the consensus seemed to be that it was not
worth the effort, but maybe we need to revisit that. We certainly seem
to be doing a lot more work now to get Postgres to
David E. Wheeler [EMAIL PROTECTED] writes:
On Jul 13, 2008, at 10:19, Tom Lane wrote:
BTW, actually a better idea would be to put citext.sql at the front of
the list and just run the whole main regression series with it
present.
typ_sanity and oidjoins might possibly find issues too.
Um,
David E. Wheeler [EMAIL PROTECTED] writes:
Could I supply two comparison files, one for Mac OS X with en_US.UTF-8
and one for everything else, as described in the last three paragraphs
here?
The fallacy in that proposal is the assumption that there are only two
behaviors out there. Let me
David E. Wheeler [EMAIL PROTECTED] writes:
On Jul 12, 2008, at 14:57, Tom Lane wrote:
4. A lot of the later test cases are equally uselessly testing whether
piggybacking over text functions works.
I'd like to keep these tests, since they ensure not just that the
functions work but that
Pavan Deolasee [EMAIL PROTECTED] writes:
(taking the discussions to -hackers)
On Sat, Jul 12, 2008 at 11:02 PM, Tom Lane [EMAIL PROTECTED] wrote:
(2) It achieves speedup of VACUUM by pushing work onto subsequent
regular accesses of the page, which is exactly the wrong thing.
Worse, once you
All,
I am attempting to build postgres 8.3.3 under Visual Studio 2008, and I
get the following error in the build:
.\src\backend\libpq\pqcomm.c(389): error C2065: 'IPPROTO_IPV6' :
undeclared identifier
Our IT department has asked us to upgrade all our systems from VS2005 to
2008. Though
Knight, Doug [EMAIL PROTECTED] writes:
I am attempting to build postgres 8.3.3 under Visual Studio 2008, and I
get the following error in the build:
.\src\backend\libpq\pqcomm.c(389): error C2065: 'IPPROTO_IPV6' :
undeclared identifier
[ squint... ] They define IPV6_V6ONLY and AF_INET6 but
Dear Hackers,
it has been two years, since I've presented my work on Postgres-R for
the first time to a broader audience in Toronto. I continued maintaining
that code in my spare time, but to be honest, I didn't have much time
for it.
As much as I'd like to change that, I now think the best
On Mon, Jul 14, 2008 at 4:21 PM, Knight, Doug [EMAIL PROTECTED] wrote:
Has anyone tried successfully to build postgres under VS2008?
I know neither Magnus or I have tried yet, and I doubt any of the
other hackers have either.
--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
--
Sent
On Mon, 2008-07-14 at 17:42 +0200, Markus Wanner wrote:
As much as I'd like to change that, I now think the best thing for the
project itself is to open it up and release the source code. I'd very
much like to get others aboard and turn Postgres-R into a real
community project again. Of
On Mon, Jul 14, 2008 at 11:42 AM, Markus Wanner
[EMAIL PROTECTED] wrote:
As a first step towards a community project, I've cleaned up the code and
tried to comment and document it as good as I can. You are welcome to
download the latest patch from http://www.postgres-r.org/downloads/. It
Tom Lane [EMAIL PROTECTED] writes:
It strikes me that what you are trying to do here is compensate for
a bad decision in the HOT patch, which was to have VACUUM's first
pass prune/defrag a page even when we know we are going to have to
come back to that page later. What about trying to fix
On Jul 14, 2008, at 01:34, Martijn van Oosterhout wrote:
I am not in favor of adding more database-specific types to ANY
database
- and I think PostGres doing it was a mistake.
So you think that adding full text indexing, gist/gin indexes, text,
geometric types should have waited until the
Awhile back I was objecting to Pavel's table-function patch on the
grounds that it introduced a new proargmodes value (thereby breaking
every client that looks at proargmodes) for what seemed to me to be
entirely insignificant benefits. I still consider that patch mostly
useless syntactic sugar,
On Jul 14, 2008, at 06:05, Andrew Dunstan wrote:
You can certainly add any tests you like. But the buildfarm does all
its regression tests using an install done with --no-locale. Any
test that requires some locale to work, or make sense, should
probably not be in your Makefile's REGRESS
On Jul 14, 2008, at 07:24, Tom Lane wrote:
David E. Wheeler [EMAIL PROTECTED] writes:
Could I supply two comparison files, one for Mac OS X with
en_US.UTF-8
and one for everything else, as described in the last three
paragraphs
here?
The fallacy in that proposal is the assumption that
On Jul 14, 2008, at 07:26, Tom Lane wrote:
I'd like to keep these tests, since they ensure not just that the
functions work but that they work with citext.
It might be reasonable to test a couple of them for that purpose.
If your agenda is test every function in the system that comes or
might
On Jul 14, 2008, at 06:49, Alvaro Herrera wrote:
So this whole area would seem to need a lot of love ...
Do the tests control for platforms, as well, since locales with the
same spellings can vary on different platforms? Or even on different
versions of the same platforms?
Thanks,
Gregory Stark [EMAIL PROTECTED] writes:
I like the idea of only having to do a single pass through the table though.
Well, that argument was already overstated: we're not re-reading all of
the table now. Just the pages containing dead line pointers.
Couldn't Pavan's original plan still work
David E. Wheeler wrote:
On Jul 14, 2008, at 06:05, Andrew Dunstan wrote:
You can certainly add any tests you like. But the buildfarm does all
its regression tests using an install done with --no-locale. Any test
that requires some locale to work, or make sense, should probably not
be in
On Jul 14, 2008, at 10:55, Andrew Dunstan wrote:
No.
--no-locale is the same as --locale=C which means the encoding is
SQL_ASCII.
I've used --no-locale --encoding UTF-8 many times. But if the
regressions run with SQL_ASCII…well, I'm just amazed that there
haven't been more unexpected
David E. Wheeler [EMAIL PROTECTED] writes:
Well, unless the display of the characters would be broken (the build
farm databases use UTF-8, no?),
No, they use C.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
On Jul 14, 2008, at 10:58, Tom Lane wrote:
Well, unless the display of the characters would be broken (the build
farm databases use UTF-8, no?),
No, they use C.
Um, you mean SQL_ASCII?
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
David E. Wheeler [EMAIL PROTECTED] writes:
On Jul 14, 2008, at 07:24, Tom Lane wrote:
The fallacy in that proposal is the assumption that there are only two
behaviors out there.
Well, no, that's not the assumption at all. The assumption is that the
type works properly with multibyte
Kless wrote:
Yes, they must be managed by the language. Which is why it should be
part of the standard. That way, changing databases does not require
changing code.
You are correct that putting widely used features into a standard that
is implemented by everyone is good.
This does not
On Jul 14, 2008, at 11:06, Tom Lane wrote:
[ shrug... ] Seems pretty useless to me: we already know that it
works
for you. The point of a regression test in my mind is to make sure
that
it works for everybody. Given the platform variations involved in
strcoll's behavior, the definition
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
I like the idea of only having to do a single pass through the table though.
Well, that argument was already overstated: we're not re-reading all of
the table now. Just the pages containing dead line pointers.
I write here the answer of Jerry Stuckle [1] because it looks me
interesting and enough logical.
[1]
http://groups.google.com/group/comp.databases.mysql/browse_thread/thread/89557609239a995e
---
Quite frankly, I don't care that PostGres has user-defined types.
They
restrict
Unfortunately I had to uninstall VS2005 to install VS2008 due to limited
space, or I'd search the old libraries to see where the symbol used to
be. Anyone care to search their VS2005 includes for IPPROTO_IPV6 so I
can compare to the VS2008?
Also, following the usual build procedure (using
On Jul 14, 2008, at 10:49, Kless wrote:
I write here the answer of Jerry Stuckle [1] because it looks me
interesting and enough logical.
It just sounds narrow-minded to me. See:
http://www.oreillynet.com/pub/a/network/2005/07/29/cjdate.html
Best,
David
--
Sent via pgsql-hackers mailing
Kless wrote:
I write here the answer of Jerry Stuckle [1] because it looks me
interesting and enough logical.
[1]
http://groups.google.com/group/comp.databases.mysql/browse_thread/thread/89557609239a995e
---
Quite frankly, I don't care that PostGres has user-defined
Kless wrote:
I write here the answer of Jerry Stuckle [1] because it looks me
interesting and enough logical.
Jerry's answer isn't a real answer - and we don't care what MySQL does
or does not do. PostgreSQL developers are not going to invest time into
helping you get a feature into MySQL
David E. Wheeler [EMAIL PROTECTED] writes:
On Jul 14, 2008, at 11:06, Tom Lane wrote:
Let me put it another way: if we test on another platform and find out
that strcoll's behavior is different there, are you going to fix that
version of strcoll? No, you're not. So you might as well just
On Jul 14, 2008, at 11:49, Tom Lane wrote:
You don't seem to understand what I'm suggesting: I'm not talking
about testing strcoll. I'm talking about making sure that citext
*uses* strcoll.
This seems pointless, as well as essentially impossible to enforce by
black-box testing. Nobody is
Mark Mielke [EMAIL PROTECTED] writes:
Kless wrote:
Yes, they must be managed by the language. Which is why it should be
part of the standard. That way, changing databases does not require
changing code.
You are correct that putting widely used features into a standard that is
On Jul 11, 2008, at 2:17 PM, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
I don't want to discard this idea, because we're getting a very
unusually high number of bogus entries. However, they are all (or a
very high percentage of them) the very first entry on each index
page.
I
Gregory Stark [EMAIL PROTECTED] writes:
Mark Mielke [EMAIL PROTECTED] writes:
I'm sure one or two examples must exist, but I cannot think of any. Every
enhancement I can think of that eventually made it into a standard, was first
implemented within a popular product, and then demanded as a
Ken Camann wrote:
In trying to port postgres to 64-bit Windows, I've encountered a
number of issues which may (or may not) affect other compilers. If
you followed the other thread, this is mostly a summary with a bit
more details so feel free to ignore it. Some of these may have some
minor
Gregory Stark wrote:
Mark Mielke [EMAIL PROTECTED] writes:
I'm sure one or two examples must exist, but I cannot think of any. Every
enhancement I can think of that eventually made it into a standard, was first
implemented within a popular product, and then demanded as a standard to be
Bruce Momjian [EMAIL PROTECTED] writes:
Ken Camann wrote:
When I try to compile postgres, I get 396 warnings. These come from
several different places:
1.) Most of the code involving strings requires a ILP32 or ILP64 to
not generate a warning. This means sizeof(int) == sizeof(size_t) ==
Stuart Gundry wrote:
I am setting up a postgres database on a standalone system with a randomized
text password. However, the db will contain very sensitive data and my boss
is worried about the possibility of someone being able to crack the db data
if they stole the machine. Can anyone point
On Jul 12, 2008, at 15:13, David E. Wheeler wrote:
2. It's ridiculously slow; at least a factor of ten slower than doing
equivalent tests directly in SQL. This is a very bad thing. Speed
of
regression tests matters a lot to those of us who run them a dozen
times
per day --- and I do not
On Mon, Jul 14, 2008 at 05:42:21PM +0200, Markus Wanner wrote:
Dear Hackers,
it has been two years, since I've presented my work on Postgres-R for
the first time to a broader audience in Toronto. I continued maintaining
that code in my spare time, but to be honest, I didn't have much time
David Fetter wrote:
On Mon, Jul 14, 2008 at 05:42:21PM +0200, Markus Wanner wrote:
Would you mind if I were to make a git branch for it on
http://git.postgresql.org/ ?
That's very likely wasted effort, since obviously Markus has got a
Monotone tree somewhere ...
--
Alvaro Herrera
On Mon, Jul 14, 2008 at 05:35:28PM -0400, Alvaro Herrera wrote:
David Fetter wrote:
On Mon, Jul 14, 2008 at 05:42:21PM +0200, Markus Wanner wrote:
Would you mind if I were to make a git branch for it on
http://git.postgresql.org/ ?
That's very likely wasted effort, since obviously
David Fetter wrote:
On Mon, Jul 14, 2008 at 05:35:28PM -0400, Alvaro Herrera wrote:
David Fetter wrote:
On Mon, Jul 14, 2008 at 05:42:21PM +0200, Markus Wanner wrote:
Would you mind if I were to make a git branch for it on
http://git.postgresql.org/ ?
That's very likely wasted
Added to TODO:
* Improve ability to modify views via ALTER TABLE
http://archives.postgresql.org/pgsql-hackers/2008-05/msg00691.php
---
Robert Haas wrote:
I think the real problem here is that
On Tue, Jul 08, 2008 at 02:41:45PM -0400, Jan Wieck wrote:
Here,
I talked to my supervisor here in Toronto (that's where I am this week)
and Afilias actually sees enough value in this for me to go and spend
time officially on it.
Yay!
The ideas I have so far are as follows:
Down in
On Tue, Jul 08, 2008 at 06:01:05PM +0900, Tatsuo Ishii wrote:
Here is the patches he made against CVS HEAD (as of today).
According to him followings are fixed with the patches:
- fix crush with DISTINCT
- fix creating VIEW
- fix the case when recursion plan has another recursion plan
On Mon, 2008-07-14 at 14:41 -0700, David Fetter wrote:
On Mon, Jul 14, 2008 at 05:35:28PM -0400, Alvaro Herrera wrote:
David Fetter wrote:
On Mon, Jul 14, 2008 at 05:42:21PM +0200, Markus Wanner wrote:
Would you mind if I were to make a git branch for it on
On Mon, Jul 14, 2008 at 04:22:47PM -0700, Joshua D. Drake wrote:
On Mon, 2008-07-14 at 14:41 -0700, David Fetter wrote:
On Mon, Jul 14, 2008 at 05:35:28PM -0400, Alvaro Herrera wrote:
David Fetter wrote:
On Mon, Jul 14, 2008 at 05:42:21PM +0200, Markus Wanner wrote:
Would you
On Jul 14, 2008, at 16:54, David Fetter wrote:
Of course, I am personally happy with SVN but hey :P
You can't have tried a merge in SVN if that's so :P :P
Those of us who have been doing it for years, in CVS and in SVN,
aren't too worried about it.
Best,
David
--
Sent via
On 15/07/2008, David E. Wheeler [EMAIL PROTECTED] wrote:
Of course, I am personally happy with SVN but hey :P
You can't have tried a merge in SVN if that's so :P :P
Those of us who have been doing it for years, in CVS and in SVN, aren't too
worried about it.
Follow the sandal! :D
Wow. I adjusted the patch slightly and applied it; the updated version
is attached. We have been waiting for this to be done for quite some
time. Thanks.
---
Dickson S. Guedes wrote:
Hi all,
These patch implements
Alvaro Herrera wrote:
Hans-Juergen Schoenig wrote:
when thinking of REASSIGNED OWNED people tend to think about tables
rather than about CONNECT rights.
i would suggest to make DROP ROLE just kill the role unless there is a
real object depending on it.
i would not see a permission
On Thu, 2008-07-10 at 16:11 -0400, Tom Lane wrote:
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] wrote:
I don't want the tag there at all, much less converted to a pointer.
What would the semantics be of copying the node, and why?
Please justify why you must
Attached a new patch that:
1. fixes previous bug
2. better handles the case when cover size is greater than the MaxWords.
Basically it divides a cover greater than MaxWords into fragments of
MaxWords, resizes each such fragment so that each end of the fragment
contains a query word and then
On Sat, 12 Jul 2008, Abhijit Menon-Sen wrote:
At 2008-07-12 00:52:42 +0100, [EMAIL PROTECTED] wrote:
The later versions of mine had a GUC named effective_spindle_count
which I think is nicely abstracted away from the implementation
details.
Yes, that does sound much better. (The patch I
On Jul 14, 2008, at 07:08, Tom Lane wrote:
You're really making it into another test. Just copy the citext.sql
file into the sql/ subdirectory and add a citext entry to the
schedule
file.
The last time I did this, I had to at least touch a corresponding
expected file (expected/citext.out)
68 matches
Mail list logo
