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
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:
> 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,
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
>
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
> 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
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
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
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:
> 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
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
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
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:
>> 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:
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
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,
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
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
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
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
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
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
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
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
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
>
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
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
> >
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
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
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
30 matches
Mail list logo
