Just wanted to say thanks again for the help to those that responded. For anyone curious, this helped me get a more advanced constraint exclusion feature finished for the partition manager I've been working on
http://www.keithf4.com/managing-constraint-exclusion-in-table-partitioning/
http://www.keithf4.com/managing-constraint-exclusion-in-table-partitioning/
On Mon, Jan 6, 2014 at 11:33 AM, Keith Fiske <keith@xxxxxxxxxx> wrote:
Thanks everyone else that replied as well!David,That seems to have fixed it! I was going down a path of grabbing the column's type from pg_attribute and trying to work from there, but was still having some of the same issues.
On Mon, Jan 6, 2014 at 10:42 AM, David Johnston <polobo@xxxxxxxxx> wrote:
Adrian Klaver-3 wrote
>>Right idea if the loss of original type in the min/max query is acceptable
>>
>> In the real function I'm writing, the columns to be used in the string
>> being created are pulled from a configuration table, so their types
>> could be anything. So casting the quote_literal() calls is not really an
>> option here.
>>
>> Any help would be appreciated.
>
> Cast before the quote_literal?
>
> Example:
>
> EXECUTE 'SELECT min('||v_col||'::text) as min, max('||v_col||'::text) as
> max FROM test_temp' INTO v_record;
(which it should be). But the cast wants to be of the min/max RESULT not
the min/max INPUT.
SELECT min(' || v_col || ')::text AS min_text, max(' || v_col || ')::text AS
max_text FROM ...
Min/Max logic wants to be done by the rules for the original type, not
according to string collation rules.
David J.
--
View this message in context: http://postgresql.1045698.n5.nabble.com/Planning-error-in-dynamic-string-creation-in-plpgsql-tp5785421p5785523.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
