Re: [BUGS] Column Name parameter problem
On Wed, Sep 28, 2005 at 12:25:54PM -0700, vishal saberwal wrote: > hi, > > I am trying to create a stored procedure that takes a column name as > parameter and then uses it to sort the table for result set. > > create or replace function ptest_Sort_Select(varchar) returns setof ptest1 > as $$ > DECLARE > res ptest1%ROWTYPE; > BEGIN > for res in > select * from ptest1 order by ptest1.$1 asc > loop > return next res; > end loop; > return; > END; > $$ language plpgsql strict; But you might try ... for res in execute 'select * from ptest1 order by ' || $1 || ' asc' loop ... i.e. build up the query string and run with execute. > but the output was not sorted. > > Then i tried this stored procedure: > create or replace function test(varchar) returns int as $$ > DECLARE > res int; > BEGIN > res:=0; > raise notice 'select * from ptest1 order by $1 asc'; I don't think plpgsql expands variables within strings. You'll have to concatenate yourself, like so: raise notice 'select * from ptest1 order by ' || $1 || ' asc'; HTH -- tomas signature.asc Description: Digital signature
Re: [BUGS] importing from 8.0.3 unicode problem
On Sun, Oct 30, 2005 at 12:23:00PM -0800, Theodore Petrosky wrote: > I don't know if this is a bug or my not understanding > something. [...] > I get an error: > ERROR: invalid UNICODE byte sequence detected near > byte 0x8e > CONTEXT: COPY ioinfo, line 177, column publication: > "Elle D?cor" > ERROR: invalid UNICODE byte sequence detected near > byte 0xa5 [...] Everything indicates that you have an iso-8859-1 `e with acute' there. So whatever went wrong, it was at (or before) dump time. Regards -- tomás signature.asc Description: Digital signature
Re: [BUGS] BUG #2037: user function call unexpected "input out of range"
On Fri, Nov 11, 2005 at 09:26:47PM +, Tom wrote: > > The following bug has been logged online: > > Bug reference: 2037 > Logged by: Tom > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.1-beta4 > Operating system: Windows XP > Description:user function call unexpected "input out of range" > Details: [ basically acos(sin(w1)*sin(w2) + cos(w1)*cos(w2)*cos(l1-l2)) ] Seems to me that you are hitting an unfortunate roundoff error, where the argument to acos is slightly greater than 1 (it will be mathematically 1 in the case w1==w2 and l1==l2). Maybe you should limit the argument to acos to -1..+1? regards -- tomás signature.asc Description: Digital signature
Re: [BUGS] Double sequence increase on single insert with RULE on targeted table
On Tue, Nov 15, 2005 at 11:39:37AM +0200, Sarunas Krisciukaitis wrote:
> Dear All,
>
> A program produces the wrong output for any given input.
> Here comes bug report:
> 1. Database dump is attached.
> 2. Input: "BEGIN; INSERT INTO test1(some_text) VALUES ('test1'); SELECT
> lastval() as id; END;"
> 3. Output:
> INSERT 0 1
> id
>
> 3
> (1 row)
> 4. Exspected Output:
> id
>
> 2
> (1 row)
[snip]
AFAIK, serials are not guaranteed to produce sequential values; tehy
will produce unique values. That means that they can (and sometimes
will) jump.
Think about it: how could a database achieve that when the rollback of
an ongoing transaction is always possible?
Regards
-- tomas
signature.asc
Description: Digital signature
Re: [BUGS] Double sequence increase on single insert with RULE on targeted table
On Tue, Nov 15, 2005 at 10:51:10PM -0700, Michael Fuhr wrote: > On Wed, Nov 16, 2005 at 06:29:40AM +0100, Tomas Zerolo wrote: > > AFAIK, serials are not guaranteed to produce sequential values; tehy > > will produce unique values. That means that they can (and sometimes > > will) jump. > > In this particular case, however, the behavior is due to the rule > on test1: > > CREATE RULE test1_on_insert AS ON INSERT TO test1 > DO INSERT INTO test_log1 (qid) VALUES (new.id); [...] Oops, I didn't see that. Your eyes are sharper than mine ;-) thanks -- tomas signature.asc Description: Digital signature
Re: [BUGS] BUG #2071: ERROR: invalid multibyte character for locale
On Fri, Nov 25, 2005 at 11:55:44AM +, Prakash Nair wrote: > > The following bug has been logged online: > > Bug reference: 2071 > Logged by: Prakash Nair > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.0.4 > Operating system: RHES > Description:ERROR: invalid multibyte character for locale > Details: > > Hello, > > Got the error in postgres console when we do a lower() or upper(). > > Postgres console gives following error, > > ERROR: invalid multibyte character for locale > HINT: The server's LC_CTYPE locale is probably incompatible with the > database encoding. > > Can any one please help me, I need to use Unicode encoding for my database. > (Not able to upgrade to postgres 8.10. as I was getting someother issues > when I try to restore database) See the related, previous post. Basically there are four places where encoding might be relevant: - Did you create the database in utf-8 encoding? (probably yes) - What is the nevironment of the server process? That is: what does the shell command 'locale' say when it is issued in the same environment as the server starts? (that is not necessarily the environment you get if you start a shell!). Try, e.g. putting ''export LANG=us_US.UTF-8'' just before the server is called (typically in /etc/init.d/postgresql or thereabout. - What is your client's encoding (issue the SQL command ''SHOW CLIENT_ENCODING'' to learn about that (or ''SET CLIENT_ENCODING'' to change that) - What is the locale of your client? (if it's on an unix-like system, see above. Otherwise I have no idea). Hope that helps -- tomas signature.asc Description: Digital signature
Re: [BUGS] BUG #2175: 22021: invalid byte sequence for encoding \"UNICODE\":
On Mon, Jan 16, 2006 at 11:55:12PM +, Roberto wrote: > > The following bug has been logged online: > > Bug reference: 2175 > Logged by: Roberto > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.0 > Operating system: windows XP > Description:22021: invalid byte sequence for encoding \"UNICODE\": > Details: > > when I go to insert one string with accent in the bank of the following o > error: > 22021: invalid byte sequence for encoding \"UNICODE\": This usually means that the encoding of your client is not UTF-8. Try some query like "SET client_encoding TO 'LATIN1'" to see if the problem disappears. Better yet -- try to convince the client to use UTF-8 encoding. HTH -- tomas signature.asc Description: Digital signature
Re: [BUGS] BUG #2318: language
On Tue, Mar 14, 2006 at 09:30:29AM +, Mete Akdogan wrote: > > The following bug has been logged online: > > Bug reference: 2318 [...] This is not a bug (and definitely not a PostgreSQL bug ;-) > hi, i am a teaching assistant in www.deu.edu.tr, in one of our db courses, > we are planning to teach from postgresql. but pgadmin's language is changing > to Turkish due to opsys regional settings. [...] Just give pgadmin another environment: from the command line type export LANG=C pgadmin & If you are using a graphical desktop you then can install a command line lime this in the starter button/menu for pgadmin. signature.asc Description: Digital signature
Re: [BUGS] BUG #2318: language
On Thu, Mar 16, 2006 at 01:02:57PM +0100, Andreas Pflug wrote: > Tomas Zerolo wrote: [...] > > export LANG=C pgadmin & > > This is a wrong advice. > Mete, use the option dialog to select your favourite language. Don't > touch the environment. OK, I assume you *do* know, gven your mail address ;-) OTOH I'd expect an application to honour the locale settings as defaults. Or how does the app know to speak turkisch in the first place? Thanks -- tomás signature.asc Description: Digital signature
Re: [BUGS] BUG #2317: Wrong sorting order for (VW)
On Thu, Mar 16, 2006 at 11:03:59AM +0100, Tomas Klockar wrote: [...] > I would say that sorting V and W as the same character may work in a > dictionary [...] > Currently the sortingfunction in postgreSQL have disqualified itself > from beeing used, and I do the sorting in java which treat them as > separate caracters. > > This is my 5 cent, Tomas, as it has been said, PostgreSQL uses the operating system's locale. So you can do two things: change it (e.b. to C , which is neutral) or fix it. If you are on an unix-like OS, man 5 locale might help with that. Regards -- tomás signature.asc Description: Digital signature
Re: [BUGS] BUG #2360: Backup produces "ERROR: could not convert UTF8 character to ISO8859-1"
On Mon, Mar 27, 2006 at 10:20:23AM +, JP Glutting wrote: > > The following bug has been logged online: > > Bug reference: 2360 > Logged by: JP Glutting > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.1 (8.0) > Operating system: Windows XP SP2 > Description:Backup produces "ERROR: could not convert UTF8 character > to ISO8859-1" > Details: > > There seems to be a bug in version 8.1 that produces this error when doing a > pg_dump (or pg_dumpall) of a database with certain characters in it. I am > not sure exactly which characters they are, but they did not cause a problem > in Postgres 8.0, because some of the databases that I cannot backup were > backed up from 8.0 and restored into 8.1 (there are also problems with data > entered directly into Postgres 8.1). Could it be that the client encoding changed from restore to backup? Which encoding is the backend using? Which one the client? (to see the backend encoding (it's fixed once you build the DB), just psql the database and issue \l (list databases). To show/set the client encoding do "SHOW client_encoding" or "SET client_encoding TO ..." Or just use \encoding if you are using psql). PostgreSQL tries to translate back and forth between encodings, but alas, you can't translate every (utf8 encoded) UNICODE to latin1, for example... Regards -- tomás signature.asc Description: Digital signature
Re: [BUGS] BUG #2400: 'Ã
On Tue, Apr 18, 2006 at 11:34:53PM +, Yusuf Siddiqui wrote:
>
> The following bug has been logged online:
>
> Bug reference: 2400
> Logged by: Yusuf Siddiqui
> Email address: [EMAIL PROTECTED]
> PostgreSQL version: 8.1
> Operating system: Linux
> Description:'Ã' considered invalid UTF-8 character
> Details:
>
> The character 'Ã' is rejected as an invalid UTF-8 character.
Well, maybe it is :-)
> Here are the steps used to recreate it:
>
> create table test (text_field text);
> insert into test (text_field) values ('Ã');
>
> Returned error:
> invalid UTF-8 byte sequence detected near byte 0x92
[...]
I'd need to know more. I gather from your mail that you are entering the
character into psql from a console. Several factors are relevant here:
- which character encoding does your console have?
(if it is, e.g. iso-8859-x then this will be probably the culprit)
- which client encoding is set? (in psql type SHOW CLIENT_ENCODING;)
- which encoding is the server using (I'd guess utf-8; it doesn't need
to be the same as the client's, since it will try to convert).
HTH
-- tomás
signature.asc
Description: Digital signature
