Heikki Linnakangas [EMAIL PROTECTED] writes:
Ignoring my general dislike of enums, I have a few issues with the patch
as it is:
1. What's the point of having comparison operators for enums? For most
use cases, there's no natural ordering of enum values.
If you would like to be able to
Magnus Hagander wrote:
Also, it compiles fine on MSVC. I still haven't managed to get the MingW
build environment working properly on Win64 even for building Win32
apps, so I haven't been able to build it on MingW yet. It *should* work
since it's all standard functions, but might require further
On Mon, Dec 18, 2006 at 08:56:22PM -0800, Joshua D. Drake wrote:
On Mon, 2006-12-18 at 23:46 -0500, Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
Oh, you mean MB vs Mb. Man, it had to be that simple :)
ISTM we had discussed whether guc.c should accept units strings in
a
Simon Riggs [EMAIL PROTECTED] wrote:
I think what you are saying is: VACUUM places blocks so that they are
immediately reused. This stops shared_buffers from being polluted by
vacuumed-blocks, but it also means that almost every write becomes a
backend dirty write when VACUUM is working,
Magnus Hagander wrote:
Is it possible to add an error hint to the message? Along the line of
HINT: Did you perhaps get your casing wrong (with better wording,
of course).
Or how about we just make everything case-insensitive -- but
case-preserving! -- on Windows only?
--
Peter Eisentraut
I suspect we might need to create a pg_off_t type or some
such gadget.
Bleah.
But it does need to be fixed.
Bummer. That might be what's needed, but I'm going to at least try to
find some neater way first. I wonder why it didn't happen on MSVC...
I don't see how the error
On Tue, Dec 19, 2006 at 10:01:05AM +0100, Peter Eisentraut wrote:
Magnus Hagander wrote:
Is it possible to add an error hint to the message? Along the line of
HINT: Did you perhaps get your casing wrong (with better wording,
of course).
Or how about we just make everything
On 12/18/06, Tom Lane [EMAIL PROTECTED] wrote:
Gregory Stark [EMAIL PROTECTED] writes:
Hm, I suppose. Though starting a second gdb is a pain. What I've done in
the
past is introduce a usleep(3000) in strategic points in the backend
to
give me a chance to attach.
There is already an
Takayuki Tsunakawa [EMAIL PROTECTED] wrote:
I performed some simple tests, and I'll show the results below.
(1) The default case
235 80 226 77 240
(2) No write case
242 250 244 253 280
(3) No checkpoint case
229 252 256 292 276
(4) No fsync() case
236 112 215 216 221
(5)
Heikki Linnakangas wrote:
I'm sorry I missed the original discussions, but I have to ask: Why
do we want enums in core? The only potential advantage I can see over
using a look-up table and FK references is performance.
The difference is that foreign-key-referenced data is part of your data
Hi,
From: Hiroshi Saito [EMAIL PROTECTED]
Subject: Re: [HACKERS] pg_restore fails with a custom backup file
Date: Fri, 15 Dec 2006 00:57:50 +0900
Win32 does not implement fseeko() and ftello(). So I think it limit to
handle a 2GB file. Is this a specification?
Yes, Magnus-san suggested
Martijn van Oosterhout wrote:
On Fri, Dec 01, 2006 at 10:37:07AM -0500, Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
Seems to me that you could just do this by setting stdin to be
/dev/null?
No, because the simple_prompt code makes a point of reading from
Alvaro Herrera wrote:
So did we get anywhere with this? I'd propose something like
--non-interactive rather than --daemon-mode. Was there a patch
submitted?
With the enhanced connection string management, wouldn't it suffice to
pass a (fake/empty) password to pg_dump on the command line?
On Tue, Dec 19, 2006 at 09:59:05PM +0900, Yoshiyuki Asaba wrote:
Hi,
Win32 does not implement fseeko() and ftello(). So I think it limit to
handle a 2GB file. Is this a specification?
Yes, Magnus-san suggested the problem. It is present TODO. The entire
adjustment was still
one of our customers here found a bug in PL/pgSQL.
this is how you can create this one:
CREATE OR REPLACE FUNCTION public.make_victim_history () RETURNS
trigger AS $body$ DECLARE
schemarec RECORD;
exec_schemaselect text;
curs2 refcursor;
BEGIN
exec_schemaselect := 'SELECT nspname
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
1. What's the point of having comparison operators for enums? For most
use cases, there's no natural ordering of enum values.
If you would like to be able to index enum columns, or even GROUP BY one,
you need those; whether
Hans-Juergen Schoenig wrote:
[...]
a quick fix is to prevent the language from freeing the tuple twice -
this should safely prevent the core dump here.
we still have to make sure that the tuple if freed properly. stay tuned.
here is the patch ...
this seems to be already fixed with:
Magnus Hagander wrote:
On Tue, Dec 19, 2006 at 09:59:05PM +0900, Yoshiyuki Asaba wrote:
Hi,
Win32 does not implement fseeko() and ftello(). So I think it limit to
handle a 2GB file. Is this a specification?
Yes, Magnus-san suggested the problem. It is present TODO. The
oh sorry, i think i missed that one ...
many thanks,
hans
On Dec 19, 2006, at 3:42 PM, Stefan Kaltenbrunner wrote:
Hans-Juergen Schoenig wrote:
[...]
a quick fix is to prevent the language from freeing the tuple
twice - this should safely prevent the core dump here.
we still
Andrew Dunstan wrote:
As for efficiency, I agree with what Tom says about alignment and
padding dissolving away any perceived advantage in most cases. If we
ever get around to optimising record layout we could revisit it.
I don't, because there are always those that are knowledgeable enough
However, did you test the actual backend after that change? Given where you
change the define of off_t, that would affect every call in the backend
that uses off_t, and it just seems very strange that you could get away
with that without touching anything else? (If we're lucky, but I
wouldn't
Alvaro Herrera wrote:
Andrew Dunstan wrote:
As for efficiency, I agree with what Tom says about alignment and
padding dissolving away any perceived advantage in most cases. If we
ever get around to optimising record layout we could revisit it.
I don't, because there are always those
Alvaro Herrera [EMAIL PROTECTED] writes:
I don't, because there are always those that are knowledgeable enough to
know how to reduce space lost to padding. So it would be nice to have
2-byte enums on-disk, and resolve them based on the column's typid. But
then, I'm not familiar with the
Andrew Dunstan [EMAIL PROTECTED] writes:
I'm not a big fan of ordering columns to optimise record layout, except in the
most extreme cases (massive DW type apps). I think visible column order should
be logical, not governed by physical considerations.
Well as long as we're talking shoulds the
Did you see this from Andreas?
MinGW has fseeko64 and ftello64 with off64_t.
Maybe we need separate macros for MSVC and MinGW. Given the other
You mean something quick and dirty like this ? That would work.
Andreas
pg_dump_fseeko64.patch
Description: pg_dump_fseeko64.patch
On Tue, Dec 19, 2006 at 04:25:18PM +0100, Zeugswetter Andreas ADI SD wrote:
Did you see this from Andreas?
MinGW has fseeko64 and ftello64 with off64_t.
Maybe we need separate macros for MSVC and MinGW. Given the other
You mean something quick and dirty like this ? That
Gregory Stark wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I'm not a big fan of ordering columns to optimise record layout, except in the
most extreme cases (massive DW type apps). I think visible column order should
be logical, not governed by physical considerations.
Well as
MinGW has fseeko64 and ftello64 with off64_t.
Maybe we need separate macros for MSVC and MinGW. Given the other
You mean something quick and dirty like this ? That would work.
Yes, except does that actually work? If so you found the place in the
headers to stick it
On Tue, Dec 19, 2006 at 10:48:41AM -0500, Andrew Dunstan wrote:
Sure, but the only sane way I can think of to do that would be have
separate logical and physical orderings, with a map between the two. I
guess we'd need to see what the potential space savings would be and
establish what the
Greetings,
Subject pretty much says it all. I've put up with this error in the
past when it has caused me trouble but it's now starting to hit our
clients on occation which is just unacceptable.
The way I've seen it happen, and this is just empirically so I'm not
sure that it's
I have updated my Synchronized Scan patch and have had more time for
testing.
Go to http://j-davis.com/postgresql/syncscan-results10.html
where you can download the patch, and see the benchmarks that I've run.
The results are very promising. I did not see any significant slowdown
for
I have written an article about the complexities of companies
contributing to open source projects:
http://momjian.us/main/writings/pgsql/company_contributions/
If you have any suggestions, please let me know. I am going to add a
link to this from the developer's FAQ.
--
Bruce
The 8.2.0 release went well. We spent a month more in beta than we
planned, but that time helped to eliminate many bugs, and many that had
existed in previous PostgreSQL major releases as well. We have had very
few bug reports for 8.2.0, and will be doing a minor release in 1-2
weeks to get
On Tue, 2006-12-19 at 09:07 -0800, Jeff Davis wrote:
I have updated my Synchronized Scan patch and have had more time for
testing.
Go to http://j-davis.com/postgresql/syncscan-results10.html
where you can download the patch, and see the benchmarks that I've run.
The results are very
On Tue, 2006-12-19 at 12:11 -0500, Bruce Momjian wrote:
I have written an article about the complexities of companies
contributing to open source projects:
http://momjian.us/main/writings/pgsql/company_contributions/
If you have any suggestions, please let me know. I am going to add
On Tue, 2006-12-19 at 17:43 +, Simon Riggs wrote:
On Tue, 2006-12-19 at 09:07 -0800, Jeff Davis wrote:
I have updated my Synchronized Scan patch and have had more time for
testing.
Go to http://j-davis.com/postgresql/syncscan-results10.html
where you can download the patch, and see
Simon Riggs [EMAIL PROTECTED] writes:
Like to see some tests with 2 parallel threads, since that is the most
common case. I'd also like to see some tests with varying queries,
rather than all use select count(*). My worry is that these tests all
progress along their scans at exactly the same
On Tue, 2006-12-19 at 18:05 +, Gregory Stark wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Like to see some tests with 2 parallel threads, since that is the most
common case. I'd also like to see some tests with varying queries,
rather than all use select count(*). My worry is that
Joshua D. Drake wrote:
On Tue, 2006-12-19 at 12:11 -0500, Bruce Momjian wrote:
I have written an article about the complexities of companies
contributing to open source projects:
http://momjian.us/main/writings/pgsql/company_contributions/
If you have any suggestions, please let
On Tue, 2006-12-19 at 13:38 -0500, Bruce Momjian wrote:
Joshua D. Drake wrote:
On Tue, 2006-12-19 at 12:11 -0500, Bruce Momjian wrote:
I have written an article about the complexities of companies
contributing to open source projects:
On 12/20/06, Bruce Momjian [EMAIL PROTECTED] wrote:
Thanks for the feedback, sectioning fixed.
Spelling mistake:
because they have gone though a company process
to
because they have gone *through* a company process
Regards,
--
[EMAIL PROTECTED]
[EMAIL PROTECTED] gmail | hotmail | yahoo
Fixed, thanks.
---
Gurjeet Singh wrote:
On 12/20/06, Bruce Momjian [EMAIL PROTECTED] wrote:
Thanks for the feedback, sectioning fixed.
Spelling mistake:
because they have gone though a company process
to
On 12/20/06, Bruce Momjian [EMAIL PROTECTED] wrote:
Fixed, thanks.
Follwing statement seems to be a bit mangled:
then when company('s?) needs diverge, going *it*(?) alone, then returning to
the community process at some later time.
--
[EMAIL PROTECTED]
[EMAIL PROTECTED] gmail | hotmail |
Gurjeet Singh wrote:
On 12/20/06, Bruce Momjian [EMAIL PROTECTED] wrote:
Fixed, thanks.
Follwing statement seems to be a bit mangled:
then when company('s?) needs diverge, going *it*(?) alone, then returning to
the community process at some later time.
Thanks, clarified.
--
Hi,
I think another point you need to bring out more clearily is that the
community is also often miffed if they feel they have been left out of
the design and testing phases. This is sometimes just a reflex that is
not always based on technical reasoning. Its just that as you correctly
Hello,
O.k. below are some comments. Your article although well written has a
distinct, from the community perspective ;) and I think there are some
points from the business side that are missed.
---
Employees working in open source communities have two bosses -- the
companies that employ them,
Joshua D. Drake wrote:
O.k. in all Bruce I like your article but I must admit it seems to take
a The community is god perspective and that we must all bend to the
will of said community.
The community could learn a great deal from adopting some of the more
common business practices when it
On 12/20/06, Joshua D. Drake [EMAIL PROTECTED] wrote:
O.k. in all Bruce I like your article but I must admit it seems to take
a The community is god perspective and that we must all bend to the
will of said community.
I'm not really in a position to judge how a company thinks about
donating
Magnus Hagander wrote:
We need different macrosand possibly functions, yes.
I think I got enough patched at home last night to get it working with
this, I was just too focused on one set of macros at the time. It's not
enough to include them very late - because off_t is used in the shared
Andrew Dunstan wrote:
Magnus Hagander wrote:
We need different macrosand possibly functions, yes.
I think I got enough patched at home last night to get it working with
this, I was just too focused on one set of macros at the time. It's not
enough to include them very late - because off_t is
On Wed, 2006-12-20 at 09:51 +1300, Andrej Ricnik-Bay wrote:
On 12/20/06, Joshua D. Drake [EMAIL PROTECTED] wrote:
O.k. in all Bruce I like your article but I must admit it seems to take
a The community is god perspective and that we must all bend to the
will of said community.
I'm not
On 12/20/06, Joshua D. Drake [EMAIL PROTECTED] wrote:
I think my overall thought is the tone seems a bit non-gracious to
companies, when IMO the community should be actively courting companies
to give resources. If companies feel unwelcome, they won't give.
I appreciate that, but then Bruce'
Joshua D. Drake wrote:
I think my overall thought is the tone seems a bit non-gracious to
companies, when IMO the community should be actively courting companies
to give resources. If companies feel unwelcome, they won't give.
I have not been following closely. But IMNSHO we should be
On Tue, 2006-12-19 at 10:01 +0100, Peter Eisentraut wrote:
Magnus Hagander wrote:
Is it possible to add an error hint to the message? Along the line of
HINT: Did you perhaps get your casing wrong (with better wording,
of course).
Or how about we just make everything case-insensitive --
On Wed, 2006-12-20 at 10:27 +1300, Andrej Ricnik-Bay wrote:
On 12/20/06, Joshua D. Drake [EMAIL PROTECTED] wrote:
I think my overall thought is the tone seems a bit non-gracious to
companies, when IMO the community should be actively courting companies
to give resources. If companies feel
On Tue, 2006-12-19 at 16:30 -0500, Andrew Dunstan wrote:
Joshua D. Drake wrote:
I think my overall thought is the tone seems a bit non-gracious to
companies, when IMO the community should be actively courting companies
to give resources. If companies feel unwelcome, they won't give.
On Tue, 2006-12-19 at 13:32 -0800, Joshua D. Drake wrote:
On Tue, 2006-12-19 at 10:01 +0100, Peter Eisentraut wrote:
Magnus Hagander wrote:
Is it possible to add an error hint to the message? Along the line of
HINT: Did you perhaps get your casing wrong (with better wording,
of
Joshua D. Drake wrote:
On Tue, 2006-12-19 at 10:01 +0100, Peter Eisentraut wrote:
Magnus Hagander wrote:
Is it possible to add an error hint to the message? Along the line of
HINT: Did you perhaps get your casing wrong (with better wording,
of course).
Or how about we just make
On Tue, 2006-12-19 at 16:47 -0500, Bruce Momjian wrote:
Joshua D. Drake wrote:
On Tue, 2006-12-19 at 10:01 +0100, Peter Eisentraut wrote:
Magnus Hagander wrote:
Is it possible to add an error hint to the message? Along the line of
HINT: Did you perhaps get your casing wrong (with
Joshua D. Drake wrote:
+ #
+ # Any memory setting may use a shortened notation such as 1024MB or
1GB.
+ # Please take note of the case next to the unit size.
+ #
Well, if you add that, you should also list all the other valid units.
But it's quite redundant, because nearly all the
On Tue, 2006-12-19 at 22:59 +0100, Peter Eisentraut wrote:
Joshua D. Drake wrote:
+ #
+ # Any memory setting may use a shortened notation such as 1024MB or
1GB.
+ # Please take note of the case next to the unit size.
+ #
Well, if you add that, you should also list all the other valid
Peter Eisentraut wrote:
Joshua D. Drake wrote:
+ #
+ # Any memory setting may use a shortened notation such as 1024MB or
1GB.
+ # Please take note of the case next to the unit size.
+ #
Well, if you add that, you should also list all the other valid units.
But it's quite redundant,
Bruce Momjian wrote:
The only value to being case-sensitive in this area is to allow
upper/lower case with different meanings, but I don't see us using
that, so why do we bother caring about the case?
Because the units are what they are.
In broader terms, we may one day want to have other
In my mind, this is pretty silly. There is no reputable precedent
anywhere for variant capitalization in unit names.
I am not suggestion variant capitalization. I am suggestion a simple
document patch to help eliminate what may not be obvious.
Good lord... *suggesting*
Joshua D. Drake
Tom Lane [EMAIL PROTECTED] writes:
Magnus Hagander [EMAIL PROTECTED] writes:
Oh, you mean MB vs Mb. Man, it had to be that simple :)
ISTM we had discussed whether guc.c should accept units strings in
a case-insensitive manner, and the forces of pedantry won the first
round. Shall we
Magnus Hagander wrote:
In most cases, I just assume they would just assume
they can't use units on it because the default value in the file
doesn't have units.
But the default value *does* have units.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
Peter Eisentraut wrote:
Magnus Hagander wrote:
In most cases, I just assume they would just assume
they can't use units on it because the default value in the file
doesn't have units.
But the default value *does* have units.
It does? Didn't in my file. I must've overwritten it with a
Lukas Kahwe Smith wrote:
Hi,
I think another point you need to bring out more clearily is that the
community is also often miffed if they feel they have been left out of
the design and testing phases. This is sometimes just a reflex that is
not always based on technical reasoning. Its
On Tue, 2006-12-19 at 23:39 +0100, Magnus Hagander wrote:
Peter Eisentraut wrote:
Magnus Hagander wrote:
In most cases, I just assume they would just assume
they can't use units on it because the default value in the file
doesn't have units.
But the default value *does* have units.
Joshua D. Drake wrote:
I am not suggestion variant capitalization. I am suggestion a simple
document patch to help eliminate what may not be obvious.
Perhaps it would be more effective to clarify the error message? Right
now it just says something to the effect of invalid integer. I'd
When psql is running and CRTL + \ is pressed, a core dumped show up.
In first place I ran psql into gdb, saw the backtrace and I believed
it was a libc6 bug and I reported to my distro security team
https://launchpad.net/distros/ubuntu/+source/glibc/+bug/76437
Ubuntu edgy has got libc-2.4, a
Kenneth Marshall [EMAIL PROTECTED] writes:
My one comment is that a little 'b' is used to indicate bits normally
and a capital 'B' is used to indicate bytes. So
kb = '1024 bits'
kB = '1024 bytes'
I do think that whether or not the k/m/g is upper case or lower case
is
Mario wrote:
When psql is running and CRTL + \ is pressed, a core dumped show up.
In first place I ran psql into gdb, saw the backtrace and I believed
it was a libc6 bug and I reported to my distro security team
https://launchpad.net/distros/ubuntu/+source/glibc/+bug/76437
This isn't a bug.
On 20/12/06, Peter Eisentraut [EMAIL PROTECTED] wrote:
Mario wrote:
When psql is running and CRTL + \ is pressed, a core dumped show up.
In first place I ran psql into gdb, saw the backtrace and I believed
it was a libc6 bug and I reported to my distro security team
Mario wrote:
On 20/12/06, Peter Eisentraut [EMAIL PROTECTED] wrote:
Mario wrote:
When psql is running and CRTL + \ is pressed, a core dumped show up.
In first place I ran psql into gdb, saw the backtrace and I believed
it was a libc6 bug and I reported to my distro security team
Gregory Stark wrote:
Kenneth Marshall [EMAIL PROTECTED] writes:
My one comment is that a little 'b' is used to indicate bits normally
and a capital 'B' is used to indicate bytes. So
kb = '1024 bits'
kB = '1024 bytes'
I do think that whether or not the k/m/g is upper
Mario wrote:
Even if you get a core dumped every time you press CTRL+\ ? why?
Try ulimit -c 0, then run it (you should get no core dump)
Then ulimit -c 50, then run it (you should get a core dump)
SIGQUIT is supposed to dump core. Ulimit settings can suppress
generation of core
Mario [EMAIL PROTECTED] writes:
On 20/12/06, Peter Eisentraut [EMAIL PROTECTED] wrote:
This isn't a bug. It's working as designed.
Even if you get a core dumped every time you press CTRL+\ ? why?
That's what C-\ does. Try it with any other program:
$ sleep 1
Quit (core dumped)
Joshua D. Drake wrote:
On Wed, 2006-12-20 at 09:51 +1300, Andrej Ricnik-Bay wrote:
On 12/20/06, Joshua D. Drake [EMAIL PROTECTED] wrote:
O.k. in all Bruce I like your article but I must admit it seems to take
a The community is god perspective and that we must all bend to the
will
Peter Eisentraut [EMAIL PROTECTED] writes:
Perhaps it would be more effective to clarify the error message? Right
now it just says something to the effect of invalid integer. I'd
imagine invalid memory unit: TB would be less confusing.
+1 on that, but I think we should just accept the
The 8.2.0 release went well. We spent a month more in beta than we
planned, but that time helped to eliminate many bugs, and many that had
existed in previous PostgreSQL major releases as well. We have had very
few bug reports for 8.2.0, and will be doing a minor release in 1-2
weeks to get
On Wed, 20 Dec 2006, Philip Yarra wrote:
Mario wrote:
Even if you get a core dumped every time you press CTRL+\ ? why?
Try ulimit -c 0, then run it (you should get no core dump)
Then ulimit -c 50, then run it (you should get a core dump)
SIGQUIT is supposed to dump core. Ulimit
The community could learn a great deal from adopting some of the more
common business practices when it comes to development as well.
In short, I guess I think it is important to recognize that both are
partners in the open source world and that to ignore one over the other
On Tue, 2006-12-19 at 19:16 -0500, Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Perhaps it would be more effective to clarify the error message? Right
now it just says something to the effect of invalid integer. I'd
imagine invalid memory unit: TB would be less confusing.
Jeremy Drake wrote:
On Wed, 20 Dec 2006, Philip Yarra wrote:
Mario wrote:
Even if you get a core dumped every time you press CTRL+\ ? why?
Try ulimit -c 0, then run it (you should get no core dump)
Then ulimit -c 50, then run it (you should get a core dump)
SIGQUIT is
Tom Lane wrote:
Nor do I believe that we'd ever accept a future patch that made
the distinction between kb and kB significant --- if you think
people are confused now, just imagine what would happen then.
As I said elsewhere, I'd imagine future functionality like a units-aware
data type,
Joshua D. Drake wrote:
I compiled and installed, ran an initdb with 32mb (versus 32MB) and
it seems to work correctly with a show shared_buffers;
Did it actually allocate 32 millibits of shared buffers?
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
Hi Asaba-san.
From: Yoshiyuki Asaba
Is it able to use fsetpos()/fgetpos() instead of ftell()/fseek()?
fpos_t is a 8byte type. I tested pg_dump/pg_restore with the attached
patch.
I'm sorry the response ..slowly...my machine reacts for the reasons of
poverty late. Last night.. I was actually
Tom Lane wrote:
+1 on that, but I think we should just accept the strings
case-insensitively, too.
I think if we'd allow this to spread, documentation, example files and
other material would use it inconsistently, and even more people would
be confused and it would make us look silly.
It's
Alvaro Herrera wrote:
I don't, because there are always those that are knowledgeable enough to
know how to reduce space lost to padding. So it would be nice to have
2-byte enums on-disk, and resolve them based on the column's typid. But
then, I'm not familiar with the patch at all so I'm not
On Wed, 2006-12-20 at 02:19 +0100, Peter Eisentraut wrote:
Joshua D. Drake wrote:
I compiled and installed, ran an initdb with 32mb (versus 32MB) and
it seems to work correctly with a show shared_buffers;
Did it actually allocate 32 millibits of shared buffers?
Funny :)
Joshua D. Drake
Peter Eisentraut wrote:
An objection to enums on the ground that foreign keys can accomplish the
same thing could be extended to object to any data type with a finite
domain.
Exactly. The extreme case is the boolean type, which could easily be
represented by a two-value enum. Or, if you were
On 12/19/06, Bruce Momjian [EMAIL PROTECTED] wrote:
This actually brings up an important distinction. Joshua is saying that
the community is painted as god in the article, and I agree there is a
basis for that, but I don't think you can consider the community and
company as equals either.
Of
Hello,
Attached is a simple patch that replaces strcmp() with pg_strcasecmp().
Thanks to AndrewS for pointing out that I shouldn't use strcasecp().
That should be AndrewD :)
J
I compiled and installed, ran an initdb with 32mb (versus 32MB) and it
seems to work correctly with a show
Joshua D. Drake [EMAIL PROTECTED] writes:
I remember the president of Great Bridge
saying that the company needs the community, but not visa-vera --- if
the company dies, the community keeps going (as it did after Great
Bridge, without a hickup), but if the community dies, the company dies
On Tue, 2006-12-19 at 22:04 -0500, Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
I remember the president of Great Bridge
saying that the company needs the community, but not visa-vera --- if
the company dies, the community keeps going (as it did after Great
Bridge, without a
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
Nor do I believe that we'd ever accept a future patch that made
the distinction between kb and kB significant --- if you think
people are confused now, just imagine what would happen then.
As I said elsewhere, I'd imagine future
Bruce Momjian [EMAIL PROTECTED] wrote:
OK, if I understand correctly, instead of doing a buffer scan, write(),
and fsync(), and recyle the WAL files at checkpoint time, you delay the
scan/write part with the some delay.
Exactly. Actual behavior of checkpoint is not changed by the patch.
Joshua D. Drake wrote:
I remember the president of Great Bridge
saying that the company needs the community, but not visa-vera --- if
the company dies, the community keeps going (as it did after Great
Bridge, without a hickup), but if the community dies, the company dies
too.
I 95%
In one fails swoop:
Sorry a beer and email just doesn't mix. The above should be one fell
swoop.
Devrim, Alvaro, Darcy, Heikki, Bruce, Simon, Greg, Dave, Marc and I are
all suddenly looking for employment...
You don't think there would be an issue that could cause some grief to
the
1 - 100 of 124 matches
Mail list logo
