Subject: ERROR: failed to find conversion function from "unknown" to text

From: "Gurjeet Singh" <[email-masked]>
Date: Tue, 6 Jan 2009 11:53:07 +0530

Q1: select '' union all select ''
Q2: select '' union all select * from (select '' ) as s

version: PostgreSQL 8.3.1, compiled by Visual C++ build 1400

Hi All,

    Q1 works just fine, but Q2 fails with:

ERROR:  failed to find conversion function from "unknown" to text

    Q2 is a generalization of a huge query we are facing, which we cannot
modify. I don't think this is a 'removed-casts' problem generally faced in
8.3, but I may be wrong. Will adding some cast resolve this?

Best regards,
-- 
gurjeet[.singh]@EnterpriseDB.com
singh.gurjeet@{ gmail | hotmail | indiatimes | yahoo }.com

EnterpriseDB      http://www.enterprisedb.com

Mail sent from my BlackLaptop device

---

From: "Pavel Stehule" <[email-masked]>
Date: Tue, 6 Jan 2009 07:30:53 +0100

Hello

> 8.3, but I may be wrong. Will adding some cast resolve this?

yes

postgres=#  select '' union all select * from (select ''::text ) as s;
 ?column?
----------

(2 rows)

regards
Pavel Stehule

---

From: "Gurjeet Singh" <[email-masked]>
Date: Tue, 6 Jan 2009 12:07:51 +0530

As I mentioned, we cannot change the query, so adding casts to the query is
not an option. I was looking for something external to the query, like a
CREATE CAST command that'd resolve the issue.

Best regards,

---

From: "Pavel Stehule" <[email-masked]>
Date: Tue, 6 Jan 2009 07:45:21 +0100

> CREATE CAST command that'd resolve the issue.

I am sorry, I blind - I tested casting on 8.3.0 and it doesn't work
(but I am have old 8.3)
postgres=# create function unknown2text(unknown) returns text as
$$select $1::text$$ language sql;
CREATE FUNCTION
postgres=# create cast(unknown as text) with function
unknown2text(unknown) as implicit;
CREATE CAST
postgres=# select '' union all select * from (select '' ) as s;
ERROR:  stack depth limit exceeded
HINT:  Increase the configuration parameter "max_stack_depth", after
ensuring the platform's stack depth limit is adequate.
CONTEXT:  SQL function "unknown2text" during startup
SQL function "unknown2text" statement 1
SQL function "unknown2text" statement 1
SQL function "unknown2text" statement 1
SQL function "unknown2text" statement 1
SQL function "unknown2text" statement 1

It working on 8.4

postgres=# create cast (unknown as text) with inout as implicit;
CREATE CAST
postgres=# select '' union all select * from (select '' ) as s;
 ?column?
----------

(2 rows)

regards
Pavel Stehule

---

From: "Gurjeet Singh" <[email-masked]>
Date: Tue, 6 Jan 2009 14:34:25 +0530

I took your cue, and have formulated this solution for 8.3.1 :

create or replace function unknown2text(unknown) returns text as
$$ begin return text($1::char); end $$ language plpgsql;

drop cast (unknown as text);

create cast (unknown as text) with function unknown2text( unknown ) as
implicit;

select '' union all select * from (select '' ) as s;

Thanks for your help Pavel.

Best regards,

PS: I was getting the same error as yours (stack depth) in EDB version
8.3.0.12, so I had to use the following code for unknown2text:

return charin( unknownout($1) );

It works for PG 8.3.1 too.

On Tue, Jan 6, 2009 at 12:15 PM, Pavel Stehule <[email-masked]>wrote:

> >> > modify. I don't think this is a 'removed-casts' problem generally
> faced
> >> > in

---

From: "Scott Marlowe" <[email-masked]>
Date: Tue, 6 Jan 2009 02:13:05 -0700

> I took your cue, and have formulated this solution for 8.3.1 :

Is there a good reason you're running against a db version with known
bugs instead of 8.3.5?  Seriously, it's an easy upgrade and running a
version missing over a year of updates is not a best practice.

---

From: "Gurjeet Singh" <[email-masked]>
Date: Tue, 6 Jan 2009 14:54:42 +0530

> version missing over a year of updates is not a best practice.

That's just a development instance that I have kept for long; actual issue
was on EDB 8.3.0.12, which the customer is using. As noted in the PS of
previous mail, the solution that worked for PG 8.3.1 didn't work on EDB
8.3.0.12, so had to come up with a different code for that!

Best regards,

---

From: "Scott Marlowe" <[email-masked]>
Date: Tue, 6 Jan 2009 02:29:00 -0700

> 8.3.0.12, so had to come up with a different code for that!

Ahh, ok.  I was just worried you were ignoring updates.  I don't know
anything about the numbering scheme for EDB.  What does 8.3.0.12
translate to in regular pgsql versions?

---

From: Tom Lane <[email-masked]>
Date: Tue, 06 Jan 2009 08:01:39 -0500

> create cast (unknown as text) with function unknown2text( unknown ) as

This is a horrendously bad idea; it will bite your *ss sooner or later,
probably sooner.

			regards, tom lane

---

From: "Gurjeet Singh" <[email-masked]>
Date: Tue, 6 Jan 2009 19:08:21 +0530

> This is a horrendously bad idea; it will bite your *ss sooner or later,

I guessed so, but couldn't figure out exactly how! That's why I have
suggested this as a temp solution until we confirmed this with someone more
knowledgeable.

Can you please let us know how this would be problematic? And can you
suggest a better solution?

Thanks and best regards,

---

From: Tom Lane <[email-masked]>
Date: Tue, 06 Jan 2009 08:48:06 -0500

> Can you please let us know how this would be problematic?

The point is that it's going to have unknown, untested effects on the
default coercion rules, possibly leading to silent changes in the
behavior of queries that used to work.  If you'd rather retest every one
of your other queries than fix this one, then go ahead.

			regards, tom lane

---

From: "Rob Richardson" <[email-masked]>
Date: Tue, 6 Jan 2009 09:06:43 -0500

Greetings!

I just tried to do a search in the archives of this list for ".Net
provider".  The search returned results contained "provided" and
"providing".  Is there a way to make sure that my searches return only
messages containing strings that exactly match what I'm looking for?

Thank you very much.

RobR

---

From: Sam Mason <[email-masked]>
Date: Tue, 6 Jan 2009 15:11:18 +0000

> messages containing strings that exactly match what I'm looking for?

would google do what you want?

  http://www.google.com/search?q=".Net+provider"+site:archives.postgresql.org/pgsql-general

  a few useful variations:

    ``intext:".net provider" site:archives.postgresql.org''
    ``intitle:".net provider" site:archives.postgresql.org''

gleaned from:

  http://www.googleguide.com/advanced_operators.html

  Sam

---

From: "Gurjeet Singh" <[email-masked]>
Date: Tue, 6 Jan 2009 23:13:59 +0530

> of your other queries than fix this one, then go ahead.
Changing the query is an option not given to us. It is being migrated from a
BigDB.

I was working on these solutions assuming that these are workarounds to a
bug. But from your mails, it seems that it is an expected behaviour; is it?

If we consider the second branch of UNION ALL of both the queries above, if
"select '' " yields a text column, then so should a "select * from (select
'')".

Its not exactly a bug, but sure is a problem that we should try to resolve.

Thanks and best regards,

---

From: Martijn van Oosterhout <[email-masked]>
Date: Tue, 6 Jan 2009 23:13:41 +0100

> "select '' " yields a text column, then so should a "select * from (select

The problem is ofcourse that "select ''" doesn't produce a text column
in postgres. This generally works fine, except in the case of UNION
where none of the branches provide the necessary type info.

Have a nice day,
-- 
Martijn van Oosterhout   <[email-masked]>   http://svana.org/kleptog/
> Please line up in a tree and maintain the heap invariant while 
> boarding. Thank you for flying nlogn airlines.