Hello,
I'm working on implementation of collation at database level using
system locales as a Google Summer of Code 2008 project. You can read my
proposal on the wiki page -
http://wiki.postgresql.org/wiki/Gsoc08-collation . I'm building this
over Alexey Slynko's patch sent two years ago
Simon Riggs <[EMAIL PROTECTED]> writes:
> My proposal is to have this as a two-stage process. When we set the hint
> on a tuple in a clean buffer we mark it BM_DIRTY_HINTONLY, if not
> already dirty. If we set a hint on a buffer that is BM_DIRTY_HINTONLY
> then we mark it BM_DIRTY.
I wonder if it
On Tue, 2008-05-27 at 20:35 +0100, Simon Riggs wrote:
> My proposal is to have this as a two-stage process. When we set the hint
> on a tuple in a clean buffer we mark it BM_DIRTY_HINTONLY, if not
> already dirty. If we set a hint on a buffer that is BM_DIRTY_HINTONLY
> then we mark it BM_DIRTY.
I
On Tue, 2008-05-27 at 23:28 +0200, Florian G. Pflug wrote:
> Simon Riggs wrote:
> > After some discussions at PGCon, I'd like to make some proposals for
> > hint bit setting with the aim to reduce write overhead.
> >
> > Currently, when we see an un-hinted row we set the bit, if possible and
> >
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Peter Eisentraut <[EMAIL PROTECTED]> writes:
>>> I think that was the first version that worked sanely in general.
>>
>> Hmm. Bruce, what gettext version are you running exactly, and how much
>> have you ever tested the localization b
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> I notice that the PGAC_CHECK_GETTEXT macro already contains the comment
> >>dnl FIXME: We should probably check for version >=0.10.36.
> >> So depending on what that's about, there might be some other good
>
Simon Riggs wrote:
After some discussions at PGCon, I'd like to make some proposals for
hint bit setting with the aim to reduce write overhead.
Currently, when we see an un-hinted row we set the bit, if possible and
then dirty the block.
If we were to set the bit but *not* dirty the block we ma
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I notice that the PGAC_CHECK_GETTEXT macro already contains the comment
>> dnl FIXME: We should probably check for version >=0.10.36.
>> So depending on what that's about, there might be some other good
>> reasons to go with cho
Thanks for the report.
> hello everybody,
>
> i did some testing with the existing WITH RECURSIVE patch.
> i found two issues with patch version 6.
> here are the details:
>
> test=# explain select count(*) from ( WITH RECURSIVE t(n) AS ( SELECT
> 1 UNION ALL SELECT n+1 FROM t ) SELECT * FROM
Tom Lane wrote:
> I notice that the PGAC_CHECK_GETTEXT macro already contains the comment
> dnl FIXME: We should probably check for version >=0.10.36.
> So depending on what that's about, there might be some other good
> reasons to go with choice #2. Peter, it appears you put that comment
After some discussions at PGCon, I'd like to make some proposals for
hint bit setting with the aim to reduce write overhead.
Currently, when we see an un-hinted row we set the bit, if possible and
then dirty the block.
If we were to set the bit but *not* dirty the block we may be able to
find a r
On Tue, May 27, 2008 at 8:05 PM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> You don't have to fix it just for me --- I can remove --enable-nls; the
> big question is who else is going to hit this. I think the buildfarm
> has safe-enough checking for 8.4, but I am concerned about the back
> branch
Bruce Momjian wrote:
> Magnus Hagander wrote:
> > > 2. Adjust the AC_SEARCH_LIBS call to probe for
> > > bind_textdomain_codeset() instead of gettext() as it does now.
> > > This would have the effect of rejecting pre-0.10.36 versions of
> > > the library.
> >
> > Depending on the buildfarm issue
Magnus Hagander wrote:
> > 2. Adjust the AC_SEARCH_LIBS call to probe for
> > bind_textdomain_codeset() instead of gettext() as it does now. This
> > would have the effect of rejecting pre-0.10.36 versions of the
> > library.
>
> Depending on the buildfarm issue it may be that the software is ant
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> We can either add a configure test or say that we don't support
> >> such old versions of gettext ...
>
> > Or we could just #ifdef the whole thing to win32, since it's not
> > really needed on other platforms,
On Tue, May 27, 2008 at 12:05 PM, Magnus Hagander <[EMAIL PROTECTED]> wrote:
> Alex Hunsaker wrote:
>> On Tue, May 27, 2008 at 10:20 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
>> > I am wondering if it's a good idea to hide the redundant entries
>> > to reduce clutter in the pg_settings display. (We
Magnus Hagander <[EMAIL PROTECTED]> writes:
>> One point of interest is that for client_min_messages and
>> log_min_messages, the ordering of the values has significance, and
>> it's different for the two cases.
> Is there any actual reason why they're supposed to be treated
> differently?
Yeah:
Tom Lane wrote:
> Most of the GUC variables that have been converted to enums have an
> extra_desc string that lists the valid values --- in HEAD, try
> SELECT name,extra_desc,enumvals from pg_settings where vartype =
> 'enum';
>
> ISTM this is just about 100% redundant with the enumvals column an
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> We can either add a configure test or say that we don't support
>> such old versions of gettext ...
> Or we could just #ifdef the whole thing to win32, since it's not
> really needed on other platforms, pushing that decision to later
Alex Hunsaker wrote:
> On Tue, May 27, 2008 at 10:20 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> > I am wondering if it's a good idea to hide the redundant entries
> > to reduce clutter in the pg_settings display. (We could do this
> > by adding a "hidden" boolean to struct config_enum_entry.)
> > T
Tom Lane wrote:
> There are several GUC enums that accept values that aren't documented
> anywhere; the worst offender being backslash_quote, which has more
> undocumented spellings than documented ones:
>
> /*
> * Although only "on", "off", and "safe_encoding" are documented, we
> * accept all
Tom Lane wrote:
> > Just for kicks, I've applied this patch so you, so you get to be on
> > the receiving side of that ;-)
>
> No objection here.
>
> I noticed that you applied the patch to 8.2 as well. It should be
> harmless enough, but we weren't having the problem in 8.2 were we?
> Or am I j
Tom Lane wrote:
> I wrote:
> > OK, so your version of libintl doesn't have bind_textdomain_codeset?
>
> Some digging in the gettext changelog suggests that
> bind_textdomain_codeset was added in gettext-0.10.36, released
> 2001-03-29.
>
> We can either add a configure test or say that we don't su
As an addendum for the archives only, I would add:
On Sun, 2008-05-25 at 20:10 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > The implementation is trivial, namely that the calculation of global
> > xmin would ignore Read Uncommitted transactions.
>
> This proposed implemen
> We can either add a configure test or say that we don't support
> such old versions of gettext ...
We don't support seems like a very reasonable response considering the
age.
Sincerely,
Joshua D. Drake
>
> regards, tom lane
>
--
Sent via pgsql-hackers mailing list
I wrote:
> OK, so your version of libintl doesn't have bind_textdomain_codeset?
Some digging in the gettext changelog suggests that
bind_textdomain_codeset was added in gettext-0.10.36, released
2001-03-29.
We can either add a configure test or say that we don't support
such old versions of gette
On Tue, May 27, 2008 at 10:20 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> I am wondering if it's a good idea to hide the redundant entries
> to reduce clutter in the pg_settings display. (We could do this
> by adding a "hidden" boolean to struct config_enum_entry.)
> Thoughts?
+1
>
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Hm, I assume you used --enable-nls ... why isn't libintl mentioned
>> in the link?
> It was cut off --- the libraries are:
> ../../src/port/libpgport_srv.a -lintl -lssl -lcrypto -lgetopt -ldl
> -lutil -lm -o postgres
OK,
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I am seeing a compile falure after this patch on BSD/OS 4.3.1. The
> > failure is during link of the backend binary:
>
> > -lssl -lcrypto -lgetopt -ldl -lutil -lm -o postgres
> > utils/mb/mbutils.o: In function `SetDatabaseEn
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I am seeing a compile falure after this patch on BSD/OS 4.3.1. The
> failure is during link of the backend binary:
> -lssl -lcrypto -lgetopt -ldl -lutil -lm -o postgres
> utils/mb/mbutils.o: In function `SetDatabaseEncoding':
> utils/m
30 matches
Mail list logo
