Guillaume Smet wrote:
On Wed, Apr 8, 2009 at 9:11 PM, I wrote:
Following the discussion here
http://archives.postgresql.org/message-id/49d9e986.8010...@pse-consulting.de
, I wrote a small patch which rotates the last XLog file on shutdown
[snip]
Any comment or advice on how I can fix it with a
Dne 24.04.09 07:17, Heikki Linnakangas napsal(a):
This diff in tsearch2.out surprised me:
@@ -2390,7 +2390,7 @@
Sea view wow foo bar qq
http://www.google.com/foo.bar.html"; target="_blank">YES
- ff-bg
+ ff-bg
document.write(15);
Any idea what's causing that?
Good ca
This diff in tsearch2.out surprised me:
@@ -2390,7 +2390,7 @@
Sea view wow foo bar qq
http://www.google.com/foo.bar.html"; target="_blank">YES
- ff-bg
+ ff-bg
document.write(15);
Any idea what's causing that?
Zdenek Kotala wrote:
Please, can somebody look on this pat
Please, can somebody look on this patch? I would like to have green
lights on my buildfarms.
thanks Zdenek
Dne 24.03.09 12:23, Zdenek Kotala napsal(a):
Dne 24.03.09 08:43, Peter Eisentraut napsal(a):
Peter Eisentraut wrote:
Andrew Dunstan wrote:
Yes, dungbeetle is ... I took tcl ou
Dne 23.04.09 23:31, Peter Eisentraut napsal(a):
On Thursday 23 April 2009 18:14:59 Zdenek Kotala wrote:
I'm looking on Makefile.shlib and I see there strange line:
# Insert -L from LDFLAGS after any -L already present in SHLIB_LINK
SHLIB_LINK := $(filter -L%, $(SHLIB_LINK)) $(filter -L%, $(LDFL
Peter Eisentraut writes:
> AFAIR, the only reason that we haven't disallowed this sort of stuff
> years and years ago is that people use it; the Japanese in particular.
> I don't see what is different now.
What's different now is that 8.4 has already established the principle
that you have to clo
On Apr 22, 2009, at 10:47 PM, Tom Lane wrote:
I think this is due to a change that was made in 8.2:
Cool. Thanks for the followup!
eric
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hacker
On Thursday 23 April 2009 22:00:25 Tom Lane wrote:
> Andrew Dunstan writes:
> > So the following sequence woiuld be illegal:
> >
> > initdb -E latin1
> > createdb -E utf8
>
> Yes, that's rather the point. Note that it already is illegal
> unless you happen to have selected C locale;
AFAIR, the o
On Thursday 23 April 2009 18:32:19 Zdenek Kotala wrote:
> however it seems to me that $rpath should be set like --with-libs, but
> it look likes that it does not work.
The rpath stuff only sets the rpath where our libraries are going to be
installed. It does not handle rpaths necessary to get ot
On Thursday 23 April 2009 18:14:59 Zdenek Kotala wrote:
> I'm looking on Makefile.shlib and I see there strange line:
>
> # Insert -L from LDFLAGS after any -L already present in SHLIB_LINK
> SHLIB_LINK := $(filter -L%, $(SHLIB_LINK)) $(filter -L%, $(LDFLAGS))
> $(filter-out -L%, $(SHLIB_LINK))
>
>
On Thu, 2009-04-23 at 16:08 -0300, pgsql-hackers-ow...@postgresql.org
wrote:
> On Thu, Apr 23, 2009 at 10:38:55AM -0400, Bill Moran wrote:
>
> [...]
>
> > It's possible that this could be accomplished by something like
> Veil,
>
> Veil? Care to share an URL?
http://veil.projects.postgresql.org/
Tom Lane píše v čt 23. 04. 2009 v 14:47 -0400:
> Zdenek Kotala writes:
> > I supposed to do something like this for libpq, libpgtypes and so on.
>
> > *** pgsql.orig.d976d4abedca/src/interfaces/libpq/Makefile 2009-04-23
> > 20:07:21.178749132 +0200
> > --- pgsql.orig/src/interfaces/libpq/Make
On Apr 23, 2009, at 12:00 PM, Tom Lane wrote:
You can get around this by cloning template0 instead of template1
(we assume template0 contains nothing that's encoding-specific).
Possibly the docs will need to be improved to emphasize that.
I was just about to suggest that. With this change, tem
Tom Lane wrote:
If we wanted to be entirely anal about this, we could allow SQL_ASCII
destination with a different source encoding, but not the reverse.
However, we currently consider that you're on your own to ensure sanity
when using SQL_ASCII as far as locale goes, so I'm not sure why the
po
Greg Stark writes:
> So it would still be possible to byass this check by cloning a
> database into SQL_ASCII and then cloning it into the desired encoding?
> Doesn't sound like it really accomplishes much.
Well, it accomplishes preventing stupid encoding violations. The point
came to mind w
So it would still be possible to byass this check by cloning a
database into SQL_ASCII and then cloning it into the desired encoding?
Doesn't sound like it really accomplishes much.
I do seem to recall some discussion about this way back. I don't
recall the conclusion but I remember some ta
In response to Tom Lane :
> Bill Moran writes:
> > In response to Tom Lane :
> >> We should presumably let the encoding be changed when cloning
> >> from template0, and probably it's reasonable to trust the user
> >> if either source or destination DB encoding is SQL_ASCII.
> >> In other cases I'
Tom Lane wrote:
Andrew Dunstan writes:
So the following sequence woiuld be illegal:
initdb -E latin1
createdb -E utf8
Yes, that's rather the point. Note that it already *is* illegal
unless you happen to have selected C locale; AFAICS that is an
oversight and not intentio
Andrew Dunstan writes:
> So the following sequence woiuld be illegal:
> initdb -E latin1
> createdb -E utf8
Yes, that's rather the point. Note that it already *is* illegal
unless you happen to have selected C locale; AFAICS that is an
oversight and not intentional. For instance, going in the o
Bill Moran wrote:
In response to Tom Lane :
We should presumably let the encoding be changed when cloning
from template0, and probably it's reasonable to trust the user
if either source or destination DB encoding is SQL_ASCII.
In other cases I'm thinking it should fail.
On a pedantic level, do
Bill Moran writes:
> In response to Tom Lane :
>> We should presumably let the encoding be changed when cloning
>> from template0, and probably it's reasonable to trust the user
>> if either source or destination DB encoding is SQL_ASCII.
>> In other cases I'm thinking it should fail.
> On a peda
Tom Lane wrote:
If I have locale set to C, I can do this:
regression=# create database u8 encoding 'utf8';
CREATE DATABASE
regression=# create database l1 encoding 'latin1' template u8;
CREATE DATABASE
Had I had any actual utf8 data in u8, l1 would now contain
encoding-corrupt information. G
Zdenek Kotala writes:
> I supposed to do something like this for libpq, libpgtypes and so on.
> *** pgsql.orig.d976d4abedca/src/interfaces/libpq/Makefile 2009-04-23
> 20:07:21.178749132 +0200
> --- pgsql.orig/src/interfaces/libpq/Makefile 2009-04-23 20:07:21.194173674
> +0200
> ***
In response to Tom Lane :
> If I have locale set to C, I can do this:
>
> regression=# create database u8 encoding 'utf8';
> CREATE DATABASE
> regression=# create database l1 encoding 'latin1' template u8;
> CREATE DATABASE
>
> Had I had any actual utf8 data in u8, l1 would now contain
> encodin
Tom Lane píše v čt 23. 04. 2009 v 11:42 -0400:
> Zdenek Kotala writes:
> > Tom Lane píše v čt 23. 04. 2009 v 11:11 -0400:
> >> What *specific* problem are you having, on what
> >> platform?
>
> > I have problem with setup builfarm member on Solaris 10. I need to pass
> > -R (rpath). I can do it
Tom Lane wrote:
If I have locale set to C, I can do this:
regression=# create database u8 encoding 'utf8';
CREATE DATABASE
regression=# create database l1 encoding 'latin1' template u8;
CREATE DATABASE
Had I had any actual utf8 data in u8, l1 would now contain
encoding-corrupt information. Giv
If I have locale set to C, I can do this:
regression=# create database u8 encoding 'utf8';
CREATE DATABASE
regression=# create database l1 encoding 'latin1' template u8;
CREATE DATABASE
Had I had any actual utf8 data in u8, l1 would now contain
encoding-corrupt information. Given that we've trie
On Apr 23, 2009, at 12:22 AM, Heikki Linnakangas wrote:
Zdenek Kotala wrote:
It seems to me that citex_cmp can return any integer value. It
depends
what wcscoll() returns. I think it should be changed to:
SELECT citext_cmp('B'::citext, 'a'::citext) > 0 AS one;
The comment in varstr_cmp() cl
Bruce Momjian writes:
> OK, I thought there was some uncertainty about whether people were using
> the AIX code.
Somebody suggested that the code might be needed on pre-5.3 AIX. But
after I looked into the files and found out the code is only needed
pre *4.3*, I think the odds of anyone still wa
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> >
> > I have received the attached email from HELIOS Software GmbH giving us
> > permission to change the licensing of HELIOS-contributed software to our
> > project to the official BSD license. (I am BCC'ing them.)
> >
> > I think we should re-add
Bruce Momjian wrote:
>
> I have received the attached email from HELIOS Software GmbH giving us
> permission to change the licensing of HELIOS-contributed software to our
> project to the official BSD license. (I am BCC'ing them.)
>
> I think we should re-add the AIX files we removed from CVS ye
Bruce Momjian writes:
> I think we should re-add the AIX files we removed from CVS yesterday,
Why? That code is ten years obsolete.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.
Zdenek Kotala writes:
> Tom Lane pÃÅ¡e v Ät 23. 04. 2009 v 11:11 -0400:
>> What *specific* problem are you having, on what
>> platform?
> I have problem with setup builfarm member on Solaris 10. I need to pass
> -R (rpath). I can do it by LD_OPTIONS as we do it for package
> building. I had onl
I have received the attached email from HELIOS Software GmbH giving us
permission to change the licensing of HELIOS-contributed software to our
project to the official BSD license. (I am BCC'ing them.)
I think we should re-add the AIX files we removed from CVS yesterday,
and then remove the non-
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, Apr 23, 2009 at 11:23:20AM -0400, Bill Moran wrote:
[...]
> > Veil? Care to share an URL?
>
> Google knows :)
>
> http://veil.projects.postgresql.org/curdocs/index.html
Thanks! [yes, Google knew, but it had so many veils it got me complete
Peter Eisentraut píše v čt 23. 04. 2009 v 18:11 +0300:
> On Thursday 23 April 2009 17:50:47 Zdenek Kotala wrote:
> > I hit a problem with libtcl.so that LDFLAGS is not propagated. The same
> > problem is with other PL languages as well.
> >
> > Is it intention or a bug?
>
> For shared libraries,
Tom Lane píše v čt 23. 04. 2009 v 11:11 -0400:
> Zdenek Kotala writes:
> > I hit a problem with libtcl.so that LDFLAGS is not propagated. The same
> > problem is with other PL languages as well.
>
> > Is it intention or a bug?
>
> It's intentional; LDFLAGS is for linking executables and may not
In response to to...@tuxteam.de:
>
> On Thu, Apr 23, 2009 at 10:38:55AM -0400, Bill Moran wrote:
>
> [...]
>
> > It's possible that this could be accomplished by something like Veil,
>
> Veil? Care to share an URL?
Google knows :)
http://veil.projects.postgresql.org/curdocs/index.html
--
Bil
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, Apr 23, 2009 at 10:38:55AM -0400, Bill Moran wrote:
[...]
> It's possible that this could be accomplished by something like Veil,
Veil? Care to share an URL?
Sorry for my ignorance
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Zdenek Kotala píše v čt 23. 04. 2009 v 16:50 +0200:
> I hit a problem with libtcl.so that LDFLAGS is not propagated. The same
> problem is with other PL languages as well.
>
> Is it intention or a bug?
I'm looking on Makefile.shlib and I see there strange line:
# Insert -L from LDFLAGS after an
On Thursday 23 April 2009 17:50:47 Zdenek Kotala wrote:
> I hit a problem with libtcl.so that LDFLAGS is not propagated. The same
> problem is with other PL languages as well.
>
> Is it intention or a bug?
For shared libraries, you need to use LDFLAGS_SL instead.
--
Sent via pgsql-hackers mailin
Zdenek Kotala writes:
> I hit a problem with libtcl.so that LDFLAGS is not propagated. The same
> problem is with other PL languages as well.
> Is it intention or a bug?
It's intentional; LDFLAGS is for linking executables and may not be
suitable for shlibs. I see that Makefile.shlib makes exce
I hit a problem with libtcl.so that LDFLAGS is not propagated. The same
problem is with other PL languages as well.
Is it intention or a bug?
thanks Zdenek
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.
In response to to...@tuxteam.de:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Thu, Apr 23, 2009 at 12:43:30PM +0100, Sam Halliday wrote:
> > Dear pgsql hackers,
> >
> > The encryption options
> >
> > http://www.postgresql.org/docs/8.3/static/encryption-options.html
>
> [...]
>
> >
"Joshua D. Drake" wrote:
> I am not opposed to making the default zero.
+1 making zero the default for 8.4
> I am also +1 on adding the warnings.
+1, but less urgent, lower priority
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, Apr 23, 2009 at 12:43:30PM +0100, Sam Halliday wrote:
> Dear pgsql hackers,
>
> The encryption options
>
> http://www.postgresql.org/docs/8.3/static/encryption-options.html
[...]
> If it were feasible, a transparent crypto on all fields for
Hi,
On Wed, Apr 22, 2009 at 9:21 PM, K, Niranjan (NSN - IN/Bangalore)
wrote:
> Starting a new thread related to synchronization of the data files, WAL
> etc.. between Primary and standby servers in Synchronous replication
> patch.
>
> Use case: Whenever the primary and standby are out of sync due
Hi,
On Thu, Apr 23, 2009 at 4:49 PM, Heikki Linnakangas
wrote:
> This is getting complicated, though. I guess it would be enough to document
> that you mustn't copy any extra files into pg_xlog if you use a fast
> trigger.
Agreed. I added this note into document.
Attached is the updated patch.
Dear pgsql hackers,
The encryption options
http://www.postgresql.org/docs/8.3/static/encryption-options.html
fall short for my thread case. Consider the case where all users of a
machine are trusted and the machine automatically locks itself down on
a period of inactivity, and only local
Heikki Linnakangas píše v čt 23. 04. 2009 v 10:22 +0300:
> Zdenek Kotala wrote:
> Comment and test case fixed.
Thanks
> I considered changing varstr_cmp to really
> return -1, 0 or 1, but I didn't because the behavior has been unchanged
> for ages and all the callers are happy with it. That'
Fujii Masao wrote:
On Wed, Apr 22, 2009 at 4:27 AM, Heikki Linnakangas
wrote:
Fujii Masao wrote:
On Tue, Apr 14, 2009 at 2:41 PM, Fujii Masao
wrote:
I'd like to propose another simple idea; pg_standby deletes the
trigger file *whenever* the nextWALfile is a timeline history file.
A timeline
Zdenek Kotala wrote:
It seems to me that citex_cmp can return any integer value. It depends
what wcscoll() returns. I think it should be changed to:
SELECT citext_cmp('B'::citext, 'a'::citext) > 0 AS one;
The comment in varstr_cmp() claims that it returns -1, 0 or 1. That's
not accurate then.
52 matches
Mail list logo
