Is there a way to return the currently logged on ID from Netezza in a view's SQL, current_sid - sql

Question

I have a SQL statement on Netezza that uses the following SQL to acquire the currently logged on user ID:
SELECT SESSION_USERNAME FROM _V_SESSION_DETAIL WHERE SESSION_ID=current_sid
This works great when I'm executing the SQL in a database client. However, when I implement the above SQL in a view (along with other SQL) the current_sid is replaced with the session ID I happened to have when I created the view. That SQL will then look something like:
SELECT DEFINITION_SCHEMA."_V_SESSION_DETAIL".SESSION_USERNAME FROM DEFINITION_SCHEMA."_V_SESSION_DETAIL" WHERE (DEFINITION_SCHEMA."_V_SESSION_DETAIL".SESSION_ID = 2434740
Is there a way to define a view that will get the currently logged on user's ID, not the ID that was assigned when the view was created?

Answer 1

Seems like Netezza Metadata functions(ex. current_sid) are not supported in with clause and would advice to remove them from with and to include them in the base query .
CREATE
OR REPLACE VIEW ADMIN.VW_PI_HRCHY_EPH AS
WITH CHAR_MASK(CHAR_MASK_CHAR) AS (
SELECT 'xxx'
FROM _V_SESSION_DETAIL LIMIT 1
)
,NUM_MASK(NUM_MASK_NUM) AS (
SELECT - 1
FROM _V_SESSION_DETAIL LIMIT 1
)
,TS_MASK(TS_MASK_TS) AS (
SELECT '1000-01-01 00:00:00'
FROM _V_SESSION_DETAIL LIMIT 1
)
SELECT CASE
WHEN SECURITY_GRP_CNT.COUNT > 0
THEN PI_HRCHY.HRCHY_LINE_ID
ELSE NUM_MASK.NUM_MASK_NUM
END AS HRCHY_LINE_ID
,CASE
WHEN SECURITY_GRP_CNT.COUNT > 0
THEN PI_HRCHY.LOCALE_CD
ELSE CHAR_MASK.CHAR_MASK_CHAR
END AS LOCALE_CD
,CASE
WHEN SECURITY_GRP_CNT.COUNT > 0
THEN PI_HRCHY.MODIFY_TS
ELSE TS_MASK.TS_MASK_TS
END AS MODIFY_TS
FROM (
SELECT COUNT(*) AS count
FROM _V_USERGROUPS
WHERE USERNAME IN (
SELECT SESSION_USERNAME
FROM _V_SESSION_DETAIL
WHERE SESSION_ID = current_sid
)
AND GROUPNAME = 'GROUP_AUTH2READ'
) SECURITY_GRP_CNT
,ADMIN.PI_HRCHY
,CHAR_MASK
,NUM_MASK
,TS_MASK
WHERE (
(PI_HRCHY.HRCHY_TYP_ID = 11)
AND (PI_HRCHY.ACTV_IND = 'Y'::"NCHAR")
);

Answer 2

The solution NzGuy provided solved my problem. As he stated, apparently placing the current_sid contact in the WITH clause of the SQL causes the constant to be evaluated differently than if it were placed outside the WITH. The common table expression defined outside the WITH clause resolved my problem.