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
www
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, cop
On 17.01.2011 14:26, Peter Geoghegan wrote:
On 17 January 2011 12:58, Susanne Ebrecht 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?
On 17 January 2011 12:58, Susanne Ebrecht 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 tend to be muc
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 pre-discu
On lör, 2009-07-25 at 01:41 -0500, Jaime Casanova wrote:
> On Fri, Jul 24, 2009 at 2:23 AM, Magnus Hagander 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
On Wed, Feb 24, 2010 at 11:07 AM, Bruce Momjian 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 based on the cl
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
On Tue, Nov 3, 2009 at 6:31 AM, Peter Eisentraut 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 enough please g
Tom Lane wrote:
> Peter Eisentraut 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
> wi
On Tue, 2009-11-03 at 09:32 -0500, Tom Lane wrote:
> Peter Eisentraut 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 connecti
Peter Eisentraut 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 set of options i
On Sun, 2009-09-27 at 21:49 -0400, Robert Haas wrote:
> On Wed, Sep 23, 2009 at 3:26 PM, Tom Lane wrote:
> > Jaime Casanova 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
On Wed, Sep 23, 2009 at 3:26 PM, Tom Lane wrote:
> Jaime Casanova 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 aro
Jaime Casanova 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 patch a bit. I hadn't unders
On Mon, Sep 14, 2009 at 3:31 PM, Andrew Chernow 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 y
Jaime Casanova writes:
> On Mon, Sep 14, 2009 at 1:55 PM, Tom Lane 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 for what
> reasons?
Every function that
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
On Mon, Sep 14, 2009 at 2:20 PM, Andrew Chernow wrote:
> Jaime Casanova wrote:
>>
>> On Mon, Sep 14, 2009 at 1:34 PM, Andrew Chernow wrote:
>>>
>>> Jaime Casanova wrote:
i extracted the functions to connect that Heikki put on psql in his
patch for determining client_encoding from c
On Mon, Sep 14, 2009 at 1:55 PM, Tom Lane wrote:
> Jaime Casanova 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.
>
i
Jaime Casanova wrote:
On Mon, Sep 14, 2009 at 1:34 PM, Andrew Chernow 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[]) appr
Jaime Casanova 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, tom lane
--
Sent via pgsql
On Mon, Sep 14, 2009 at 1:34 PM, Andrew Chernow 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 wrote:
On Thu, Sep 10, 2009 at 12:01 AM, Jaime Casanova
wrote:
On Mon, Jul 6, 2009 at 10:00 AM, Heikki
Linnakangas 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
parame
On Thu, Sep 10, 2009 at 12:01 AM, Jaime Casanova
wrote:
> On Mon, Jul 6, 2009 at 10:00 AM, Heikki
> Linnakangas 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 ar
Jaime Casanova writes:
> On Mon, Jul 6, 2009 at 10:00 AM, Heikki
> Linnakangas 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 Mon, Jul 6, 2009 at 10:00 AM, Heikki
Linnakangas 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, but we could have
> something
On Wed, Aug 19, 2009 at 11:08 AM, Jaime
Casanova wrote:
> On Tue, Aug 18, 2009 at 6:49 AM, Heikki
> Linnakangas wrote:
>>
>> Hmm, are you sure you the right version of libpq is being loaded at
>> runtime? What does "ldd ./test-libpq" say?
>>
>
attached the results of ldd and the result of the test
On Tue, Aug 18, 2009 at 6:49 AM, Heikki
Linnakangas 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 until friday...
once said that,
(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 p
On Fri, Jul 24, 2009 at 2:23 AM, Magnus Hagander 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
> individual s
On Fri, Jul 24, 2009 at 04:12, Jaime
Casanova wrote:
> On Mon, Jul 6, 2009 at 10:00 AM, Heikki
> Linnakangas 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 intr
On Mon, Jul 6, 2009 at 10:00 AM, Heikki
Linnakangas 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 when compiling a client
that uses
On Mon, Jul 6, 2009 at 10:00 AM, Heikki
Linnakangas 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 ./libpqdll.def
fe-auth.o fe-connec
On Thu, Jul 23, 2009 at 1:24 PM, Peter Eisentraut 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 something that
thi
On Thursday 23 July 2009 20:16:39 Jaime Casanova wrote:
> On Thu, Jul 23, 2009 at 11:02 AM, Tom Lane 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 shl
On Thu, Jul 23, 2009 at 11:02 AM, Tom Lane 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 one that shi
Jaime Casanova writes:
> On Wed, Jul 22, 2009 at 7:30 PM, Alvaro
> Herrera 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 pick libraries from, no?
On most Linux systems, -L
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
> `pg_g
On Wed, Jul 22, 2009 at 9:58 PM, Jaime
Casanova wrote:
> On Wed, Jul 22, 2009 at 7:30 PM, Alvaro
> Herrera 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/
On Wed, Jul 22, 2009 at 7:30 PM, Alvaro
Herrera 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
>> /usr/local/pgsql/head/lib/libpq.so:
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
On Mon, Jul 6, 2009 at 10:00 AM, 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 to
> "auto", libpq uses the encoding as returned by
> pg_get_encoding_from_locale().
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 modifi
Bruce Momjian 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 eliminat
Tom Lane wrote:
> Itagaki Takahiro writes:
> > Peter Eisentraut 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
> >>> clie
Itagaki Takahiro wrote:
Peter Eisentraut 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 cli
Itagaki Takahiro writes:
> Peter Eisentraut 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
Peter Eisentraut 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 client's locale?
On Wed, Jun 17, 2009 at 4:54 PM, Alvaro
Herrera 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 client's locale? We have
>
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 us
Peter Eisentraut 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 locale? We
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
> pg_get_encoding_from_loc
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 recentl
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 LC_CT
56 matches
Mail list logo
