Basically, API level means the Android version. This defines for which version you are targeting your application and what is going to be the minimum level of android version in your application will run. For setting Minimum level and Maximum level android studio provides two terminologies.

minSdkVersion means minimum Android OS version that will support your app and targetSdkVersion means the version for which you are actually developing your application. Your app will be compatible with all the version of android which are falling between minimum level SDK and target SDK.

How to change API SDK level in Android Studio

For changing the API level in android we have two different Approaches, let’s check both one by one:

Approach 1 To Change SDK API Level in Android Studio:

Step 1: Open your Android Studio, and go to Menu. File >Project Structure.

Step 2: In project Structure window, select app module in the list given on left side.

Step 3: Select the Flavors tab and under this you will have an option for setting Min Sdk Version” and for setting Target Sdk Version”.

You can check the name of version too in the drop down list while selecting the API level that makes the selection more clearer for anyone. Because sometimes remembering numbers is bit messy.

Step 4: Select both the versions and Click OK.

Approach 2 To Change API (Android Version) in Android Studio:

That will be pretty straight forward, but you need to stay very alert while making changes here.

Step 1: if you are project is opened in android option then select open Gradle Scripts > build.gradle(Module: app)

if you are in project View then click on your project folder > app > build.gradle

Step 2: Here you have to change minimum and Maximum sdk level as per your requirement. check the below given code:

defaultConfig {
    applicationId "com.AbhiAndroid.Android.myProject"
    minSdkVersion 14
    targetSdkVersion 23
    versionCode 1
    versionName "1.0"
}

Step 3: Click on Sync Now and You are ready to go.

Note: If you are choosing the First Approach then you need not to make changes in Gradle. It will automatically update the gradle.

Server side

If you want something easy to re-use or automate, you can use Postgresql's built in COPY command. e.g.

Copy (Select * From foo) To '/tmp/test.csv' With CSV DELIMITER ',';

This approach runs entirely on the remote server - it can't write to your local PC. It also needs to be run as a Postgres "superuser" (normally called "root") because Postgres can't stop it doing nasty things with that machine's local filesystem.

That doesn't actually mean you have to be connected as a superuser (automating that would be a security risk of a different kind), because you can use the SECURITY DEFINER option to CREATE FUNCTION to make a function which runs as though you were a superuser.

The crucial part is that your function is there to perform additional checks, not just by-pass the security - so you could write a function which exports the exact data you need, or you could write something which can accept various options as long as they meet a strict whitelist. You need to check two things:

I've written a blog post expanding on this approach, including some examples of functions that export (or import) files and tables meeting strict conditions.

Client side

The other approach is to do the file handling on the client side, i.e. in your application or script. The Postgres server doesn't need to know what file you're copying to, it just spits out the data and the client puts it somewhere.

The underlying syntax for this is the COPY TO STDOUT command, and graphical tools like pgAdmin will wrap it for you in a nice dialog.

The psql command-line client has a special "meta-command" called \copy, which takes all the same options as the "real" COPY, but is run inside the client:

\copy (Select * From foo) To '/tmp/test.csv' With CSV

Note that there is no terminating ;, because meta-commands are terminated by newline, unlike SQL commands.

From the docs:

Your application programming language may also have support for pushing or fetching the data, but you cannot generally use COPY FROM STDIN/TO STDOUT within a standard SQL statement, because there is no way of connecting the input/output stream. PHP's PostgreSQL handler (not PDO) includes very basic pg_copy_from and pg_copy_to functions which copy to/from a PHP array, which may not be efficient for large data sets.