Hive Strange code syntax test.`(submit_date)?+.+ - hive

I have a HQL(Hive Query) file which has code like
select * ,'(submit_date)?+.+' from test
Table test has several other filed after submit date all of which are returned in the output of this query, but i couldn't understand how this thing works. ?
does any1 have any idea, i couldn't find any Doc related to this syntax

This is documented as the REGEX column specification:
A SELECT statement can take regex-based column specification.
We use java regex syntax. Try http://www.fileformat.info/tool/regex.htm for testing purposes.
The following query select all columns except ds and hr.
SELECT `(ds|hr)?+.+` FROM sales

Related

starts_with in presto?

I am new to writing sql queries in presto and was looking for a function similar to 'starts_with'.
If a string starts with a given substring then the query needs to return that record.
In Postgresql, I am currently doing select * from tableA where name~'^Joh'. Whats the equivalent of this in Presto?
PostgreSQL and presto are RDBMS based on SQL. It is weird to see that you've learned a PostgreSQL proprietary add on (regular expressions) to the language before learning the standard SQL functions. In SQL you use LIKE for pattern matches:
select * from tableA where name like 'Joh%';
You can use Like in SQL. You can go through this link https://www.w3schools.com/sql/sql_like.asp. Using like you can search for a specified pattern.
In presto you can use regexp_like() which runs little faster than other like operators.For your case try below query which should provide you with expected functionality.
select regexp_like('John', '^John')

regexp_like that mirrors contains near

I'm trying to speed up a query that uses Contains Near with one that uses regexp_like. The initial Contains Near query takes about 45 minutes to run. Clob Column holds large "documents" and is domain indexed.
Initial query:
SELECT column1
FROM TEST
WHERE CONTAINS(column1,'{NEAR(quick,fox, lazy), 3, FALSE}')>0;
Proposed query:
SELECT column1
FROM TEST
WHERE REGEXP_LIKE(column1, '(\b(quick|fox|lazy)(?:\W+\w+){1,6}?\W(quick|fox|lazy)(?:\W+\w+){1,}?\W(quick|fox|lazy)\b)','i')
I got the original regexp syntax from here:
https://www.regular-expressions.info/near.html.
Problem:
I get the regexp code to work in html https://www.regextester.com, but when I put it in Oracle it doesn't find anything. What is wrong with my syntax? I can't figure it out. Does Oracle handle REGEXP differently?
Alex, you were exactly right. I don't see how to select your answer as correct though.
My problem was apparently that I was using regexp parameters that Oracle doesn't recognize. So, whereas it worked on https://www.regextester.com, it failed to work in Oracle because most of what I used isn't recognized as usable with regexp in Oracle. I really think Oracle should expand their regexp codes it recognized. This was really frustrating.

What does "SELECT INTO" do?

I'm reading sql code which has a line that looks like this:
SELECT INTO _user tag FROM login.user WHERE id = util.uuid_to_int(_user_id)::oid;
What exactly does this do? The usual way to use SELECT INTO requires specifying the columns to select after the SELECT token, e.g.
SELECT * INTO _my_new_table WHERE ...;
The database is postgresql.
This line must appear inside of a PL/pgSQL function. In that context the value from column tag is assigned to variable _user.
According to the documentation:
Tip: Note that this interpretation of SELECT with INTO is quite different from PostgreSQL's regular SELECT INTO command, wherein the INTO target is a newly created table.
and
The INTO clause can appear almost anywhere in the SQL command. Customarily it is written either just before or just after the list of select_expressions in a SELECT command, or at the end of the command for other command types. It is recommended that you follow this convention in case the PL/pgSQL parser becomes stricter in future versions.

Hive: Select * command is not working similar to RDBMS

I installed apache hive-0.9.0 and start executing some basic commands and i found one abnormal behavior in select* command. In select statement after * any random characters are allowed in hive but in RDBMS its not allowed. I am not sure its expected behavior or bug in hive. Could some please confirm?
In the below query "abcdef" is random characters.
In RDBMS(oracle):
select *abcdef from mytable;
Output:
ERROR prepare() failed with: ORA-00923: FROM keyword not found where expected
In Hive:
select *abcdef from mytable;
Output:
Query worked fine and display all the records of mytable.
In RDBMS,select is followed by column name/* , but in HIVE,it may be column name/*/any regular expression(partitions) .
Go through this link
http://www.qubole.com/5-tips-for-efficient-hive-queries/
it provides whole description
I got response from apache hive committe. Its a indeed bug in hive. They filed a improvement ticket for this issue
Jira Ticket: https://issues.apache.org/jira/browse/HIVE-8155

Bind variables in the from clause for Postgres

I'm attempting to write an extension for SQL Developer to better support Postgres. These are just XML configuration files with SQL snippets in them. To display the values for a postgres sequence, I need to run a simple query of the following form:
select * from schema.sequence
The trouble with this is that the Oracle SQL Developer environment provides the correct schema and node (sequence) name as bind variables. This would mean that I should format the query as:
select * from :SCHEMA.:NAME
The trouble with this is that bind variables are only valid in the select clause or the where clause (as far as I'm aware), and using this form of the query returns a "syntax error at or near "$1" error message.
Is there a way to return the values in the sequence object without directly selecting them from the sequence? Perhaps some obtuse joined statement from pg_catalog tables?
Try this:
select *
from information_schema.sequences
where sequence_name = :name
and sequence_schema = :schema;
It's not exactly the same thing as doing a select from the sequence, but the basic information is there.