An Idea Exchange for SAS software and services

by Regular Contributor
on ‎02-28-2017 06:00 PM

I see your point, so I upvoted your suggestion.


I'm very interested to know more from a programming languages point of view (i.e., that of the software architect/developers). I can see why the length would be processed after the case logic. I'm not sure why you can't run



, case when 1 then quote(X) length=302 end as CASE


...moving the "length" statement into the case logic.




by PROC Star
on ‎02-28-2017 06:14 PM

Other issues that I wish were improved but do not belong to this discussion.
Just in case the head of PROC SQL development is looking. Wishful thinking...

1- Mentioning the length does not work for all functions. For example repeat() still trims at 200

2- Mentioning the length does not work with embedded functions. For example cat(cat(X)) fails to compute

3- Functions don't all behave the same way when option length= is not set. That's inconsistent.
    trim() derives the length from its parameter while prxparse() trims to 200 while quote() returns a blank value.

4- In the second example, quote() works as expected but issues a NOTE: Invalid argument to function QUOTE.

5- More generally, 1) we need more coherence and 2) not being able to use functions on some strings in proc sql because values are trimmed is a painful limitation that should not be accepted.

by PROC Star
‎02-28-2017 06:19 PM - edited ‎02-28-2017 07:33 PM


Thank you!

I reckon that the length should be carried to functions by proc sql rather than a language change, but any improvement is welcome!

This would allow proc sql to also carry the length not only when functions are embedded in a case clause, but also when functions are embedded in other functions.



Idea Statuses
Top Liked Authors