Re: Database->ServerEncoding, ClientEncoding

Поиск
Список
Период
Сортировка
От Dave Page
Тема Re: Database->ServerEncoding, ClientEncoding
Дата
Msg-id FED2B709E3270E4B903EB0175A49BCB104761A@dogbert.vale-housing.co.uk
обсуждение исходный текст
Ответ на Database->ServerEncoding, ClientEncoding  (Jean-Michel POURE <jm.poure@freesurf.fr>)
Ответы Re: Database->ServerEncoding, ClientEncoding
Список pgadmin-hackers

> -----Original Message-----
> From: Jean-Michel POURE [mailto:jm.poure@freesurf.fr]
> Sent: 26 February 2002 10:54
> To: pgadmin-hackers@postgresql.org
> Subject: Re: [pgadmin-hackers] Database->ServerEncoding,
> ClientEncoding
>
>
> Le Mardi 26 Février 2002 11:21, Dave Page a écrit :
> > Do we set system encoding per database, or per server.
> > Where do we set it?
> > How do we set it?
>
> Yesterday, tried a hack in SQLExecute, applying
> CLIENT_ENCODING on the fly at
> the beginning of each SQL query. There does not seem to be a
> real overhead.

Sounds a little messy to me, and will certainly clutter up logs and things.

> > Do we set user/data encoding per database or per server
> > Where do we set it (bear in mind that there is no SQLInput
> form if the
> > user does a 'View Data')? How do we set it?
>
> It would be better if we could set it per database (?) in
> pgDatabase->DataEncoding and pgDatabase->SystemEncoding.

Yes, I think I agree.

> In SQLInput, if a user does not choose a special encoding, we apply
> pgDatabase->DataEncoding as default.

I think the neatest place to set these will be in frmDatabase. Doing it
elsewhere will just be confusing. For most users, they can just leave them
alone, someone like yourself can just set & forget.

This would have to be stored in the registry - HKCU\Software\pgAdmin
II\Encodings\>Connection ID>\<Database Name>\[DataEncoding | systemEncoding]
- where <Connection ID> is of the form user|server|port as we using in the
Connections MRU list.

So, when a database is first connected, we read the relevant value and issue
a SET CLIENT_ENCODING. If pgDatabase->SystemEncoding gets updated, we write
to the registry, and issue another SET CLIENT_ENC...

That will work for System stuff. On the User/Data side, those queries *only*
come from frmSQLInput or a 'View Data' (iirc). For these types of query,
*if* we had a second connection to the database, then it could maintain it's
client encoding neatly as well. This would also have the advantage that
large queries would not be using the system connections and could
effectively give us a 'threaded' effect.

The downside would be that we would have extra connections (potentially
double). This could be minimised by only connecting on first use.

Thoughts?

Regards, Dave.



В списке pgadmin-hackers по дате отправления:

Предыдущее
От: Jean-Michel POURE
Дата:
Сообщение: Locale, Encoding
Следующее
От: Dave Page
Дата:
Сообщение: Re: Locale, Encoding