On 17.01.2011 20:18, Peter Eisentraut wrote:
That may be worth investigating, but I don't think it's related to the
present patch.
As I already said - not at all.
The patch was ok for me.
Susanne
--
Susanne Ebrecht - 2ndQuadrant
PostgreSQL Development, 24x7 Support, Training and Services
On 14.01.2011 20:12, Peter Eisentraut wrote:
I have adjusted your old patch for the current tree, and it seems to
work. I think it was just forgotten last time because the move to
PQconnectdbParams had to happen first. But I'll throw it back into the
ring now.
Hello,
maybe i missed
On 17 January 2011 12:58, Susanne Ebrecht susa...@2ndquadrant.com wrote:
Hello,
maybe i missed pre-discussion but ...
I miss considering auto-detect of file encoding.
A simple example:
$ psql -f dump.sql db
What happens when dump.sql is written by using
another encoding?
That doesn't
On 17.01.2011 14:26, Peter Geoghegan wrote:
On 17 January 2011 12:58, Susanne Ebrechtsusa...@2ndquadrant.com wrote:
Hello,
maybe i missed pre-discussion but ...
I miss considering auto-detect of file encoding.
A simple example:
$ psql -f dump.sql db
What happens when dump.sql is written by
On mån, 2011-01-17 at 14:59 +0100, Susanne Ebrecht wrote:
I didn't thought about pg_dump dump files here.
I more thought about files that came out of editors using mad encoding
and maybe then also were created on Windows and then copied to
Unix for import.
Written on little endian, copied
On lör, 2009-07-25 at 01:41 -0500, Jaime Casanova wrote:
On Fri, Jul 24, 2009 at 2:23 AM, Magnus Hagandermag...@hagander.net wrote:
1) it introduces a dependency for -lpgport when compiling a client
that uses libpq
http://archives.postgresql.org/pgsql-hackers/2009-07/msg01511.php
Did this patch go anywhere? Is it a TODO?
---
Heikki Linnakangas wrote:
Here's my first attempt at setting client_encoding automatically from
locale.
It adds a new conninfo parameter to libpq, client_encoding. If set
On Wed, Feb 24, 2010 at 11:07 AM, Bruce Momjian br...@momjian.us wrote:
Did this patch go anywhere? Is it a TODO?
There were problems with that patch, maybe Heikki will review it again
for 9.1 but for now it's already a TODO, it's in the Multi-Language
Support section
Set client encoding
On Tue, Nov 3, 2009 at 6:31 AM, Peter Eisentraut pete...@gmx.net wrote:
Is anyone planning to do further work on this? This appears to be
blocking the client_encoding=auto feature.
yes, i'm planning to make an attempt to do it as soon as i get some
time... but if you think it's important
On Sun, 2009-09-27 at 21:49 -0400, Robert Haas wrote:
On Wed, Sep 23, 2009 at 3:26 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Jaime Casanova jcasa...@systemguards.com.ec writes:
i extracted the functions to connect that Heikki put on psql in his
patch for determining client_encoding from client
Peter Eisentraut pete...@gmx.net writes:
Is anyone planning to do further work on this? This appears to be
blocking the client_encoding=auto feature.
Huh? Why would there be any linkage? This is just offering an
alternative way to set connection options, it has nothing to do
with what the
On Tue, 2009-11-03 at 09:32 -0500, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
Is anyone planning to do further work on this? This appears to be
blocking the client_encoding=auto feature.
Huh? Why would there be any linkage? This is just offering an
alternative way to set
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
Is anyone planning to do further work on this? This appears to be
blocking the client_encoding=auto feature.
Huh? Why would there be any linkage? This is just offering an
alternative way to set connection options, it has nothing to
On Wed, Sep 23, 2009 at 3:26 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Jaime Casanova jcasa...@systemguards.com.ec writes:
i extracted the functions to connect that Heikki put on psql in his
patch for determining client_encoding from client locale and put it in
libpq so i follow the
Jaime Casanova jcasa...@systemguards.com.ec writes:
i extracted the functions to connect that Heikki put on psql in his
patch for determining client_encoding from client locale and put it in
libpq so i follow the PQconnectdbParams(* params[]) approach.
I got around to looking at the actual
On Thu, Sep 10, 2009 at 12:01 AM, Jaime Casanova
jcasa...@systemguards.com.ec wrote:
On Mon, Jul 6, 2009 at 10:00 AM, Heikki
Linnakangasheikki.linnakan...@enterprisedb.com wrote:
Could we
have a version of PQconnectdb() with an API more suited for setting the
params programmatically? The
Jaime Casanova wrote:
On Thu, Sep 10, 2009 at 12:01 AM, Jaime Casanova
jcasa...@systemguards.com.ec wrote:
On Mon, Jul 6, 2009 at 10:00 AM, Heikki
Linnakangasheikki.linnakan...@enterprisedb.com wrote:
Could we
have a version of PQconnectdb() with an API more suited for setting the
params
On Mon, Sep 14, 2009 at 1:34 PM, Andrew Chernow a...@esilo.com wrote:
Jaime Casanova wrote:
i extracted the functions to connect that Heikki put on psql in his
patch for determining client_encoding from client locale and put it in
libpq so i follow the PQconnectdbParams(* params[]) approach.
Jaime Casanova jcasa...@systemguards.com.ec writes:
i put the new function at the end of the exports.txt file, there's a
reason to renumber the exports to put it at the beginning with the
other PQconnectdb function?
Exports.txt numbers do not change. EVER.
regards,
Jaime Casanova wrote:
On Mon, Sep 14, 2009 at 1:34 PM, Andrew Chernow a...@esilo.com wrote:
Jaime Casanova wrote:
i extracted the functions to connect that Heikki put on psql in his
patch for determining client_encoding from client locale and put it in
libpq so i follow the PQconnectdbParams(*
On Mon, Sep 14, 2009 at 1:55 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Jaime Casanova jcasa...@systemguards.com.ec writes:
i put the new function at the end of the exports.txt file, there's a
reason to renumber the exports to put it at the beginning with the
other PQconnectdb function?
On Mon, Sep 14, 2009 at 2:20 PM, Andrew Chernow a...@esilo.com wrote:
Jaime Casanova wrote:
On Mon, Sep 14, 2009 at 1:34 PM, Andrew Chernow a...@esilo.com wrote:
Jaime Casanova wrote:
i extracted the functions to connect that Heikki put on psql in his
patch for determining client_encoding
actually, Tom said: it's hard to be sure which way is
actually more convenient without having tried coding some likely
calling scenarios both ways.
Aahhh, correct you are Daniel son :)
??? don't understand you ???
From the movie karate kid; oopps, should be Daniel San. I was trying
to be
Jaime Casanova jcasa...@systemguards.com.ec writes:
On Mon, Sep 14, 2009 at 1:55 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Exports.txt numbers do not change. Â EVER.
i didn't find any info about it, not even in the sources... should we
document that we need to put some functions in that file and
On Mon, Sep 14, 2009 at 3:31 PM, Andrew Chernow a...@esilo.com wrote:
actually, Tom said: it's hard to be sure which way is
actually more convenient without having tried coding some likely
calling scenarios both ways.
Aahhh, correct you are Daniel son :)
??? don't understand you ???
From
On Mon, Jul 6, 2009 at 10:00 AM, Heikki
Linnakangasheikki.linnakan...@enterprisedb.com wrote:
Could we
have a version of PQconnectdb() with an API more suited for setting the
params programmatically? The PQsetdbLogin() approach doesn't scale as
parameters are added/removed in future versions,
PGconn *PQconnectParams(const char **params)
Where params is an array with an even number of parameters, forming
key/value pairs. Usage example:
Maybe use the term properties (props for short) or options instead of params?
Params is already in heavy use. How about PQconnectProps(...) or
On Wed, Aug 19, 2009 at 11:08 AM, Jaime
Casanovajcasa...@systemguards.com.ec wrote:
On Tue, Aug 18, 2009 at 6:49 AM, Heikki
Linnakangasheikki.linnakan...@enterprisedb.com wrote:
Hmm, are you sure you the right version of libpq is being loaded at
runtime? What does ldd ./test-libpq say?
On Tue, Aug 18, 2009 at 6:49 AM, Heikki
Linnakangasheikki.linnakan...@enterprisedb.com wrote:
Hmm, are you sure you the right version of libpq is being loaded at
runtime? What does ldd ./test-libpq say?
i have to rebuild with the patch on linux and windows and i'm not sure
i will have time
(I finally got a chance to get back to this...)
Jaime Casanova wrote:
ok, attached a version that modifies src/interfaces/libpq/Makefile to
push chklocale.o and eliminate the dependency on libpgport, this
change also fixes the compile problem on windows
Thanks!
still, i'm not sure this
On Fri, Jul 24, 2009 at 2:23 AM, Magnus Hagandermag...@hagander.net wrote:
1) it introduces a dependency for -lpgport when compiling a client
that uses libpq
http://archives.postgresql.org/pgsql-hackers/2009-07/msg01511.php
For other parts of libpgport that are needed, we pull in the
On Fri, Jul 24, 2009 at 04:12, Jaime
Casanovajcasa...@systemguards.com.ec wrote:
On Mon, Jul 6, 2009 at 10:00 AM, Heikki
Linnakangasheikki.linnakan...@enterprisedb.com wrote:
Here's my first attempt at setting client_encoding automatically from
locale.
Sorry for the many mails on this
On Thursday 23 July 2009 02:29:23 Jaime Casanova wrote:
this little test compiles fine until i applied your patch :(
postg...@casanova1:~/pg_releases/pgtests$ gcc -o test-libpq
test-libpq.o -L/usr/local/pgsql/head/lib -lpq
/usr/local/pgsql/head/lib/libpq.so: undefined reference to
Jaime Casanova jcasa...@systemguards.com.ec writes:
On Wed, Jul 22, 2009 at 7:30 PM, Alvaro
Herreraalvhe...@commandprompt.com wrote:
Do you have an older version of libpq.so around?
the one that installed with 8.4.0 but i thougth that when you specify
-L to gcc you're telling it where to
On Thu, Jul 23, 2009 at 11:02 AM, Tom Lanet...@sss.pgh.pa.us wrote:
On most Linux systems, -L doesn't have any effect on what happens at
runtime --- the dynamic linker's search path will determine that.
Try ldd on the executable to see which shlibs really get picked up.
yeah! it's using the
On Thursday 23 July 2009 20:16:39 Jaime Casanova wrote:
On Thu, Jul 23, 2009 at 11:02 AM, Tom Lanet...@sss.pgh.pa.us wrote:
On most Linux systems, -L doesn't have any effect on what happens at
runtime --- the dynamic linker's search path will determine that.
Try ldd on the executable to see
On Thu, Jul 23, 2009 at 1:24 PM, Peter Eisentrautpete...@gmx.net wrote:
Which proves my point, because libpgport includes chkconfig.c. But this is
just a workaround.
yeah! actually the problem i had was because we need to add the
-lpgport to use pg_get_encoding_from_locale and that is
On Mon, Jul 6, 2009 at 10:00 AM, Heikki
Linnakangasheikki.linnakan...@enterprisedb.com wrote:
Here's my first attempt at setting client_encoding automatically from
locale.
when i apply your patch and try to compile in windows i get this error
dllwrap -o libpq.dll --dllname libpq.dll --def
On Mon, Jul 6, 2009 at 10:00 AM, Heikki
Linnakangasheikki.linnakan...@enterprisedb.com wrote:
Here's my first attempt at setting client_encoding automatically from
locale.
Sorry for the many mails on this issue.. i will do a recolect of my findings:
1) it introduces a dependency for -lpgport
On Mon, Jul 6, 2009 at 10:00 AM, Heikki
Linnakangasheikki.linnakan...@enterprisedb.com wrote:
Here's my first attempt at setting client_encoding automatically from
locale.
It adds a new conninfo parameter to libpq, client_encoding. If set to
auto, libpq uses the encoding as returned by
Jaime Casanova wrote:
this little test compiles fine until i applied your patch :(
postg...@casanova1:~/pg_releases/pgtests$ gcc -o test-libpq
test-libpq.o -L/usr/local/pgsql/head/lib -lpq
/usr/local/pgsql/head/lib/libpq.so: undefined reference to
`pg_get_encoding_from_locale'
Do you have
On Wed, Jul 22, 2009 at 7:30 PM, Alvaro
Herreraalvhe...@commandprompt.com wrote:
Jaime Casanova wrote:
this little test compiles fine until i applied your patch :(
postg...@casanova1:~/pg_releases/pgtests$ gcc -o test-libpq
test-libpq.o -L/usr/local/pgsql/head/lib -lpq
On Wed, Jul 22, 2009 at 9:58 PM, Jaime
Casanovajcasa...@systemguards.com.ec wrote:
On Wed, Jul 22, 2009 at 7:30 PM, Alvaro
Herreraalvhe...@commandprompt.com wrote:
Jaime Casanova wrote:
this little test compiles fine until i applied your patch :(
postg...@casanova1:~/pg_releases/pgtests$
Here's my first attempt at setting client_encoding automatically from
locale.
It adds a new conninfo parameter to libpq, client_encoding. If set to
auto, libpq uses the encoding as returned by
pg_get_encoding_from_locale(). Any other value is passed through to the
server as is.
psql is modified
Itagaki Takahiro wrote:
Peter Eisentraut pete...@gmx.net wrote:
On Wednesday 17 June 2009 14:29:26 Heikki Linnakangas wrote:
We currently require that you set client_encoding correctly, or you get
garbage in psql and any other tool using libpq. How about setting
client_encoding automatically
Tom Lane wrote:
Itagaki Takahiro itagaki.takah...@oss.ntt.co.jp writes:
Peter Eisentraut pete...@gmx.net wrote:
On Wednesday 17 June 2009 14:29:26 Heikki Linnakangas wrote:
We currently require that you set client_encoding correctly, or you get
garbage in psql and any other tool using
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
What would make sense to me is for libpq to provide the *code* for this,
but then leave it up to the client application whether to actually call
it; if not the behavior stays the same as before. Aside from
Itagaki-san's objections, that
We currently require that you set client_encoding correctly, or you get
garbage in psql and any other tool using libpq. How about setting
client_encoding automatically to match the client's locale? We have
pg_get_encoding_from_locale() function that we can use to extract the
encoding from
Heikki Linnakangas wrote:
client_encoding defaults to server_encoding, which is correct in the
typical environment where the client and the server have identical
locale settings, which I believe is why we don't see more confused
users on mailing lists. However, a partner of ours was
On Wednesday 17 June 2009 14:29:26 Heikki Linnakangas wrote:
We currently require that you set client_encoding correctly, or you get
garbage in psql and any other tool using libpq. How about setting
client_encoding automatically to match the client's locale? We have
Peter Eisentraut pete...@gmx.net writes:
On Wednesday 17 June 2009 14:29:26 Heikki Linnakangas wrote:
We currently require that you set client_encoding correctly, or you get
garbage in psql and any other tool using libpq. How about setting
client_encoding automatically to match the client's
Heikki Linnakangas wrote:
We currently require that you set client_encoding correctly, or you get
garbage in psql and any other tool using libpq. How about setting
client_encoding automatically to match the client's locale? We have
pg_get_encoding_from_locale() function that we can use
On Wed, Jun 17, 2009 at 4:54 PM, Alvaro
Herreraalvhe...@commandprompt.com wrote:
Heikki Linnakangas wrote:
We currently require that you set client_encoding correctly, or you get
garbage in psql and any other tool using libpq. How about setting
client_encoding automatically to match the
Peter Eisentraut pete...@gmx.net wrote:
On Wednesday 17 June 2009 14:29:26 Heikki Linnakangas wrote:
We currently require that you set client_encoding correctly, or you get
garbage in psql and any other tool using libpq. How about setting
client_encoding automatically to match the
Itagaki Takahiro itagaki.takah...@oss.ntt.co.jp writes:
Peter Eisentraut pete...@gmx.net wrote:
On Wednesday 17 June 2009 14:29:26 Heikki Linnakangas wrote:
We currently require that you set client_encoding correctly, or you get
garbage in psql and any other tool using libpq. How about setting
55 matches
Mail list logo
