Under MySQL, when I am doing :
SELECT #a:=concat("he","llo"),concat(#a," world")
I get "hello world".
It is very useful because you don't have to rebuild "hello" in the second field and if I wish to modify the first "concat", it will affect the second...
With complex constructions, the gain is obvious I think...
But I didn't find the same way in HiveQL and so far, I am forced to rewrite each field construction...
I know that a subselect would do the same thing but I would prefer to avoid this way (for some practical reasons...).
Related
I'm doing a search using a postgres "with recursive" construct, but I want to stop after finding a single occurrence of something in the tree. I'm not confident the "limit 1" on the calling select clause will do it. What is the conventional approach?
What I'm trying to do is, if a field is blank, use another field within WRKQRY(Query/400) in define result fields. Is this possible?
You can create an SQL view using the RUNSQLSTM command and then run a query over the view.
CREATE VIEW QTEMP/MYVIEW AS
SELECT F1, CASE WHEN F2 <> ' ' THEN F2 ELSE F3 END AS FX FROM MYLIB/MYFILE
Then tie it all together with a CL program.
PGM
DLTF FILE(QTEMP/MYVIEW)
MONMSG MSGID(CPF0000)
RUNSQLSTM SRCFILE(MYLIB/MYSRC) MBR(MYMBR)
RUNQRY QRY(MYLIB/MYQRY)
ENDPGM
Query/400 is obsolete, and should be considered deprecated. It was replaced about 2 decades ago by Query Management. Query/400 queries run under the old database optimizer (CQE) and cannot benefit from newer faster optimization techniques employed by the new optimizer (SQE). It is recommended to migrate Query/400 queries to QM Query or to DB2 Web Query.
Fortunately, Query Management Queries can be created in a prompted mode which should be very familiar to Query/400 users. Prompted-mode queries can be converted to the more powerful SQL-mode.
You can use the RTVQMQRY command to generate SQL source from the Query/400 query you have asked about Once you have the source, you can then use the CASE ... END expression given by #Mike. Create the QM query with the CRTQMQRY command, and run it with STRQMQRY.
If you still need to do this, I can show you how to do it in 3 passes of Query 400.
Yeah, I know that's not efficient but it can be done.
Take a look at CASE that should work for you.
CASE field
WHEN ' ' THEN newfield
ELSE field
END as myfield
I designed a set of tables in pgAdmin. I gave names like Products and ProductRID. I was very surprised though when I went to query this table only to find a query like this yielded unknown relation:
select * from Products
Apparently the proper way to access this is
select * from "Products"
which is very ugly. I can rename the tables to all lower case to query without quotes, but then it looks ugly. Is there any kind of a setting so that it will retain the case, but behave without case sensitivity?
No there is no magic setting. The best way to deal with case sensitivity is to not quote your relations when you are creating them. If you are early on in schema design, go ahead and rename them (and column names) to lower case. The "looks ugly" problem will go away because in your queries you can still do
SELECT * FROM Products
and it will work fine.
You may check the relative wiki to get the precise answer
Why are my table and column names not recognized in my query? Why is capitalization not preserved?
Hope it clarifies.
Why can't one use an output column in the having clause in postgresql? It doesn't change expressivity of the language anyhow, just forces people to rewrite output column definition in having clause. Is a way to avoid that, apart from putting the whole query as a subquery in SELECT * FROM (...) AS t WHERE condition ?
Bacause it's not implemented? And if you're asking why it wasn't implemented, I see 2 possible explanations:
standard doesn't require it
nobody had time to spent on it
if you'd like to have it - mail to -hackers, talk about, and then implement.
Frankly I don't see it as a big problem - it's not like you have 1000 characters to retype.
I have a temporary table (or, say, a function which returns a table of values).
I want to execute some statements for each record in the table.
Can this be done without using cursors?
I'm not opposed to cursors, but would like a more elegant syntax\way of doing it.
Something like this randomly made-up syntax:
for (select A,B from #temp) exec DoSomething A,B
I'm using Sql Server 2005.
I dont think what you want to to is that easy.
What i have found is that you can create a scalar function taking the arguments A and B and then from within the function execute an Extended Stored Procedure. This might achieve what you want to do, but it seems that this might make the code even more complex.
I think for readibility and maintainability, you should stick to the CURSOR implementation.
I would look into changing the stored proc so that it can work against a set of data rather than a single row input.
Would CROSS/OUTER APPLY do what you want if you need RBAR processing.
It's elegant, but depends on what processing you need to do