I want to
SELECT * FROM table1 WHERE name=petter
Now if there is many type of petter in table like PETTER , Petter And petter.
Want all this three (PETTER, Petter, petter) to be considered which command is for this in cognos report studio?
Or in DB2 without using 'IN' function.
I think you want UPPER (or LOWER, the effect should be the same):
SELECT *
FROM table1
WHERE UPPER(name) = 'PETTER'
Remember, though, if you have an index on name, then this won't be able to use that index. You can create (at least if you're on z/OS) an index with that function. On other platforms, you can create a generated column and create index on that.
Related
I'm selecting distinct values from tables thru Java's JDBC connector and it seems that NULL value (if there's any) is always the first row in the ResultSet.
I need to remove this NULL from the List where I load this ResultSet. The logic looks only at the first element and if it's null then ignores it.
I'm not using any ORDER BY in the query, can I still trust that logic? I can't find any reference in Postgres' documentation about this.
You can add a check for NOT NULL. Simply like
select distinct columnName
from Tablename
where columnName IS NOT NULL
Also if you are not providing the ORDER BY clause then then order in which you are going to get the result is not guaranteed, hence you can not rely on it. So it is better and recommended to provide the ORDER BY clause if you want your result output in a particular output(i.e., ascending or descending)
If you are looking for a reference Postgresql document then it says:
If ORDER BY is not given, the rows are returned in whatever order the
system finds fastest to produce.
If it is not stated in the manual, I wouldn't trust it. However, just for fun and try to figure out what logic is being used, running the following query does bring the NULL (for no apparent reason) to the top, while all other values are in an apparent random order:
with t(n) as (values (1),(2),(1),(3),(null),(8),(0))
select distinct * from t
However, cross joining the table with a modified version of itself brings two NULLs to the top, but random NULLs dispersed througout the resultset. So it doesn't seem to have a clear-cut logic clumping all NULL values at the top.
with t(n) as (values (1),(2),(1),(3),(null),(8),(0))
select distinct * from t
cross join (select n+3 from t) t2
I'm pretty new to postgres, and wanted to know how to sort my table using the upper(or lower) functions to make a case-insensitive search. I know I could do something along the lines of:
where b.name ~* '%Example%'
But that method makes my query a bit slow. So I wanted to try the following below.
Assume that table b is like this:
order | name
1 | Example
2 | example
3 | EXAMPLE
4 | ExAmPlE
Whenever I use the query:
set schema 'schem';
select UPPER(b.name),
from b
where b.name like UPPER('%Example%');
What it comes down to is the query itself. Whenever the where clause is:
where b.name like UPPER('%Example%');
Nothing displays.
where b.name like UPPER('%E%');
Example, EXAMPLE, and ExAmPlE show in all upper-case.
where b.name like UPPER('%EXAMPLE%');
Only EXAMPLE shows.
Maybe I'm not understanding postgres right, but does the upper function only show its parameter's data in all caps? What I thought was happening is that my query will take all of the examples, force them to all upper-case, and then the where clause will also be forced to upper-case, and therefore whenever I used any of the where clauses mentioned above, each of those queries would spit everything in table b.
Am I forced to having to use the format where b.name ~* '%Example%' or am I just misunderstanding this?
Postgresql strings are case sensitive and you need to use upper on columns if you want to match your upper() query.
If you want to search case insensitive, you can also use ILIKE instead of LIKE.
If you for some reason need to store case insensitive text, there is an extension citext.
There is not much difference between name LIKE '%argh%' and name ~* 'argh', these are basically the same the way we use them in this example. The ~* operator is however much more powerful as it is a case insensitive regular expression match. (Case sensitive is ~).
If you want to have a fast query where you filter on condition, you might want to reconsider if you can change condition in such a way to match the field at beginning. Then you can use normal btree index with upper:
create index b_name_idx on b (upper(name));
This is called functional index (because you use function), and in order for postgresql to use it you must also use upper on your field:
select * from b where upper(b.name) like 'argh%';
However, if you must check for containment, if searched string can be somewhere in the middle, you might want to use pg_trgm extension.
create extension pg_trgm;
create index b_name_trgmidx on b using gin (name gin_trgm_ops);
Then these both will be able to use index:
select * from b where b.name like '%argh%';
select * from b where b.name ~* 'argh';
I’d like to sort my postgres results by some fancy ranking function, but for sake of simplicity, let’s say that I’d like to add two custom rows and sort by them.
SELECT my_table.*,
extract(epoch from (age(current_date, '2012-09-12 10:43:40'::date)))/3600 AS age_in_hours
Fancy_function_counting_distance() AS distance
FROM my_table
ORDER BY distance + age_in_hours;
However, it doesn’t work, since I’m getting error: ERROR: column "distance" does not exist.
Is it possible to order my results by that custom named rows?
I’m running postgres 9.1.x
As per the SQL standard, aliases in the SELECT list are not visible in ORDER BY.
You can use column-position specification (eg ORDER BY 1,2), but that doesn't accept an expression; you cannot ORDER BY 1+2, for example. So you need to use a subquery to generate the result set then sort it in an outer query:
SELECT *
FROM (
SELECT my_table.*,
extract(epoch from (age(current_date, '2012-09-12 10:43:40'::date)))/3600 AS age_in_hours
Fancy_function_counting_distance() AS distance
FROM my_table
) x
ORDER BY distance + age_in_hours;
Suppose I have a table with a column that has repeats, e.g.
Column1
---------
a
a
a
a
b
a
c
d
e
... so on
Maybe it has hundreds of thousands of rows. Then say, I need to pull the distinct values from this column. I can do so easily in a SELECT with DISTINCT, but I'm wondering on performance?
I could also give each item in Column1 an id, and then create a new table referenced by Column1 (to normalize this more appropriately). Though, this adds extra complexity to making an insert, and adds in joins for other possible queries.
Is there some way to index just the distinct values in a column, or is the normalization thing the only way to go?
Index on column1 will considerably speed up processing of distinct, but if you are willing to trade some space and some (short) time during insert/update/delete, you can resort to materialized view. This is indexed view you might consider as dynamic table produced and maintained following view definition.
create view view1
with schemabinding
as
select column1,
count_big(*) cnt
from theTable
group by column1
-- create unique clustered index ix_view1 on view1(column1)
(Do not forget to execute commented create index command. I usually do it this way so that view definition contains index definition, reminding me to apply it if I need to change the view.)
When you want to use it be sure to add noexpand hint to force use of materialized data (this part will remain mistery to me - something created as performance enhancement is not turned on by default, but rather activated on spot).
select *
from view1 (noexpand)
Why is this working or better yet what does it represent ( replace table with an existing one )
select table.name from table
and where is it documented ( postgresql ) ?
select table.name from table
is equivalent to
select name(table) from table
which, since name is a type, is equivalent to
select cast(table as name) from table
The first table is a row variable containing all the columns from the respective table, so you will get a text representation of the row.
This is not directly documented, since it's a combination of several obscure features (some dating back to PostQUEL). In fact, this usage has been disallowed in PostgreSQL 9.1 (see the release notes under "Casting").
The name type is documented in the string types. Hidden columns are documented (off the top of my head) in the section on system catalogs, or in the internals.
You can see hidden columns in pg_attribute. Their numbers are negative:
select attum, attname
from pg_attribute
where attrelid = 'yourtable'::regclass
That should reveal xmin, xmax, ctid, oid (where applicable), etc. Might this also yield name? (I can't test on the iPad.)