Re: [BUGS] question/suggestion Message-id: <493823b5.1030...@hogranch.com>
John R Pierce wrote:
chris wood wrote:
At a detailed level (which is NOT the direction I want this thread to
go) I do not agree with your statement that my proposal has no “hope
of ACID compliance or transactional integrity”. When the “slices” are
stored back to the cloud, this is the equivalent of a commit and the
integrity thereof is as good as what ever the underlying technology
is. Is the concurrency as good as native Postgres? Of course not. Is
the commit/rollback flexibility as good as native Postgres? Again no.
But what’s the alternative? Watch cloud computing take off leaving
Postgres with the reputation of “great database software in
yesterday’s era of monolithic servers”?
even something as simple as a SERIAL sequence would be a nightmare in
a distributed cloud environment without a complex centralized
arbitrer. the same goes for most any other sort of update/query that
depends on consistency of data.
How do you reconcile a bank account when the money has been
simultaneously withdrawn from several ATMs at different locations at
the same time? "Please, sir, give us our money back?" ? I don't think
the banks would be happy with that implementation.
If the data is partitioned across the cloud ('one version of the
truth'), things like JOINs are very very difficult to implement
efficiently. take away JOINs and you might as well be doing simple
ISAM like we did back in the 70s before Codd and his Relational
Database concepts upon which SQL is based.
no, IMHO, the cloud people are better off inventing their own data
models and their own proprietary query languages suited to the
architecture. maybe SQL and its concepts of 'one version of the truth'
and 'data integrity' are quaint relics of another age, so be it.
Objecting to an idea because it is difficult to implement is not
necessarily a clincher - there are projects trying to adapt Postgres to
more cloud-like capabilities (e.g Greenplum, Netezza) - neither of these
are open source however. There is also Pgcluster, however I'm not sure
that counts as cloud-like in its architecture...
regards
Mark
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4186: set lc_messages does not work
Gevik Babakhani wrote: > My apologies on this late reply. > The way LC_MESSAGES is handled on windows is much less efficient and faulty. > While ago I started with a patch to fix some of the issues I encountered on > windows and LC_MESSAGES. But I stopped working on that patch because this > problem needed to be fixed on many other places. In Windows, handling > LC_MESSAGES will not work the same way as *nix systems, forcing us to make > ugly workarounds. (as I actually was doing with my patch) > > To my opinion, unless we think of a coherent solution for handling > LC_MESSAGES/locale for both *nix and win32 platforms, fixing lc_messages and > locale issues would break more than fixing it. > > BTW: The gettext library we are using on win32 is a very old one. This is the most recent posting on the topic, I think. Status? --- > > Regards, > Gevik. > > > > -Original Message- > > From: Magnus Hagander [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, August 05, 2008 4:54 PM > > To: Bruce Momjian > > Cc: Tom Lane; Thomas H.; pgsql-bugs@postgresql.org; Gevik Babakhani > > Subject: Re: [BUGS] BUG #4186: set lc_messages does not work > > > > Bruce Momjian wrote: > > > Tom Lane wrote: > > >> Magnus Hagander <[EMAIL PROTECTED]> writes: > > >>> Thomas H. wrote: > > so at least that explains the "changed" behaviour. nevertheless, > > LC_MESSAGES seems to be defunct - with the "locale" > > folder present, > > pg always picks the os' language and ignores the > > lc_message value. > > >>> This looks like I can reproduce though, at least on cvs head. Did > > >>> this work for you in previous versions? > > >> Maybe we were using a different build of gettext in the previous > > >> releases, one that didn't look at the same info as the > > current code? > > >> > > >> Anyway the patch mentioned at the start of the thread > > >> http://archives.postgresql.org/pgsql-patches/2008-02/msg00038.php > > >> purports to fix this. It doesn't seem to have gotten reviewed > > >> though. > > > > > > Agreed. Magnus, someone, can we get feedback on the patch > > at this URL? > > > > > > > > http://archives.postgresql.org/pgsql-patches/2008-02/msg00038.php > > > > IIRC, there was further work to be done on the patch before > > it was to be applied, and we held off the review until then. > > > > Gevik - can you comment on this? Where are we, what needs ot > > be done still? > > > > //Magnus > > -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4186: set lc_messages does not work
Tom Lane wrote: > Magnus Hagander <[EMAIL PROTECTED]> writes: > > Thomas H. wrote: > >> so at least that explains the "changed" behaviour. nevertheless, > >> LC_MESSAGES seems to be defunct - with the "locale" folder present, > >> pg always picks the os' language and ignores the lc_message value. > > > This looks like I can reproduce though, at least on cvs head. Did this > > work for you in previous versions? > > Maybe we were using a different build of gettext in the previous > releases, one that didn't look at the same info as the current code? > > Anyway the patch mentioned at the start of the thread > http://archives.postgresql.org/pgsql-patches/2008-02/msg00038.php > purports to fix this. It doesn't seem to have gotten reviewed > though. Where are we on this? -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] question/suggestion Message-id: <493823b5.1030...@hogranch.com>
chris wood wrote:
At a detailed level (which is NOT the direction I want this thread to
go) I do not agree with your statement that my proposal has no “hope
of ACID compliance or transactional integrity”. When the “slices” are
stored back to the cloud, this is the equivalent of a commit and the
integrity thereof is as good as what ever the underlying technology
is. Is the concurrency as good as native Postgres? Of course not. Is
the commit/rollback flexibility as good as native Postgres? Again no.
But what’s the alternative? Watch cloud computing take off leaving
Postgres with the reputation of “great database software in
yesterday’s era of monolithic servers”?
even something as simple as a SERIAL sequence would be a nightmare in a
distributed cloud environment without a complex centralized arbitrer.
the same goes for most any other sort of update/query that depends on
consistency of data.
How do you reconcile a bank account when the money has been
simultaneously withdrawn from several ATMs at different locations at the
same time? "Please, sir, give us our money back?" ? I don't think the
banks would be happy with that implementation.
If the data is partitioned across the cloud ('one version of the
truth'), things like JOINs are very very difficult to implement
efficiently. take away JOINs and you might as well be doing simple ISAM
like we did back in the 70s before Codd and his Relational Database
concepts upon which SQL is based.
no, IMHO, the cloud people are better off inventing their own data
models and their own proprietary query languages suited to the
architecture. maybe SQL and its concepts of 'one version of the truth'
and 'data integrity' are quaint relics of another age, so be it.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] question/suggestion Message-id: <493823b5.1030...@hogranch.com>
> yet you propose dumbing down the database even farther, without any hope of ACID > compliance, without any transactional integrity, indeed, without even really being > relational ? > at least, thats what I get from my first read of it. OK so you are a theorist/perfectionist, I can respect that. Perhaps what I meant to say instead of "dumbing down the database" was "dumbing down the use of SQL to the point where it is not much better that indexed-style reads and writes". Is my idea perfect? No, far from it, and if there are better ideas out there then great, I hope they get pushed forward. But I do believe my idea is far better than the alternative of sticking our heads in the sand and hoping that cloud computing goes away and in the mean time web developers are stuck using databases that only support very "dumbed down" SQL sub-sets/derivatives like Google's GQL or Amazon's SimpleDB query syntax. At a detailed level (which is NOT the direction I want this thread to go) I do not agree with your statement that my proposal has no "hope of ACID compliance or transactional integrity". When the "slices" are stored back to the cloud, this is the equivalent of a commit and the integrity thereof is as good as what ever the underlying technology is. Is the concurrency as good as native Postgres? Of course not. Is the commit/rollback flexibility as good as native Postgres? Again no. But what's the alternative? Watch cloud computing take off leaving Postgres with the reputation of "great database software in yesterday's era of monolithic servers"?
Re: [BUGS] BUG #3818: Cross compilation problems
Where are we on this? --- Richard Evans wrote: > Running make inside the msys shell, I get: > > /c/misc/mingw/bin > c:/misc/mingw/bin > /c/misc/mingw/bin > > running inside a plain DOS command window, I get: > > /mingw/bin > c:/misc/mingw/bin > /mingw/bin > > Msys/mingw have these funny 'system' mounts. However it looks like that > /pwd -W/ gives the most sensible output in both cases. Must be why it's > there. > > Richard > > > Richard Evans wrote: > > > >> I'm not sure why the makefiles need the current directory. pwd -W is > >> specific to mingw, I think it gives the directory in windows format. It > >> has to be changed for cross compilation otherwise you get errors. > >> > > > > What does $(CURDIR) resolve to on mingw? Try the following makefile: > > > > default: > > @echo $(shell pwd) > > @echo $(shell pwd -W) > > @echo $(CURDIR) > > > > -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4563: Translation of errors.
Tom Lane wrote: "Eugene Pimenov" <[EMAIL PROTECTED]> writes: 2) Write a code to every translation (e.g. Error 424242 inccorrect ...), so people can actually google out a solution for their problems. RTFM: http://www.postgresql.org/docs/8.3/static/errcodes-appendix.html PostgreSQL error codes are not as unique as the error messages. If you don't like translated error messages, you could just set lc_messages to en_US in your postgresql.conf. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
