Yes, the input script can include OP codes.
However, your question seems to include a misunderstanding...
"or is it always treated as a data that will be automatically pushed on the stack"
The input script isn't "treated as a data". The way it works is that the input script and the output script are concatenated together (input script first followed by output script). Then the resulting script is processed.
So, the reason that the pubkey and the signature are "pushed to the stack" with P2PKH scripts is because the input script includes instructions that push those values onto the stack.
Lets take a look at this transaction:
https://blockchain.info/tx/714db847a01bbcdf287708374c240ac31b751a4f5df5f9a6873bd1c95452b26aHere's the hex:
https://blockchain.info/rawtx/714db847a01bbcdf287708374c240ac31b751a4f5df5f9a6873bd1c95452b26a?format=hex0100000001ddc098ecd8865c66bbb114b84b167e08d5b14f0ad276c91ad6b822b8272cfb67100000006b483045022100d70a6dd6fb9e5937a3583ae6bd544b4572a6ff75e98a06f91b23b197e9ab12dd022023ba2b2992bce0e84abcafee3bd5a8c0b51b45b2e5ec1fa803b9d42cd0c6e28301210211de158e14a99bbe29606660a9e9f068911e157a8c3324347fc6e77910fb83fbffffffff01a1cc1300000000001976a91485a80598ccff62cb567a8c276f4c7b7e1b56200988ac00000000
I'll add some line breaks after each component and label those components to make it easier to follow along:
Version: 01000000
In-counter: 01
Previous Tx hash: ddc098ecd8865c66bbb114b84b167e08d5b14f0ad276c91ad6b822b8272cfb67
Previous Txout-index: 10000000
Txin-script length: 6b
Txin-script: 483045022100d70a6dd6fb9e5937a3583ae6bd544b4572a6ff75e98a06f91b23b197e9ab12dd022023ba2b2992bce0e84abcafee3bd5a8c0b51b45b2e5ec1fa803b9d42cd0c6e28301210211de158e14a99bbe29606660a9e9f068911e157a8c3324347fc6e77910fb83fb
sequence_number: ffffffff
Out-counter: 01
Value: a1cc130000000000
Txout-script length: 19
Txout-script: 76a91485a80598ccff62cb567a8c276f4c7b7e1b56200988ac
Locktime: 00000000
Taking a look at that Txout-script, you'll see the six components you expect:
76_a9_14_85a80598ccff62cb567a8c276f4c7b7e1b562009_88_ac
OP_DUP: 76
OP_HASH160: a9
PUSH 20 BYTES: 14
20 BYTES OF DATA: 85a80598ccff62cb567a8c276f4c7b7e1b562009
OP_EQUALVERIFY: 88
OP_CHECKSIG: ac
Now lets take a look at the Txin-script. It contains 4 components:
48_3045022100d70a6dd6fb9e5937a3583ae6bd544b4572a6ff75e98a06f91b23b197e9ab12dd02
2023ba2b2992bce0e84abcafee3bd5a8c0b51b45b2e5ec1fa803b9d42cd0c6e28301_21_0211de1
58e14a99bbe29606660a9e9f068911e157a8c3324347fc6e77910fb83fb
PUSH 72 BYTES: 48
72 BYTES of SIG DATA: 3045022100d70a6dd6fb9e5937a3583ae6bd544b4572a6ff75e98a06f91b23b197e9ab12dd022023ba2b2992bce0e84abcafee3bd5a8c0b51b45b2e5ec1fa803b9d42cd0c6e28301
PUSH 33 BYTES: 21
33 BYTES OF COMPRESSED PUBKEY DATA: 0211de158e14a99bbe29606660a9e9f068911e157a8c3324347fc6e77910fb83fb
The "PUSH 72 BYTES" and "PUSH 33 BYTES" in the Txin-script are the reason that the SIG and PUBKEY end up on the stack.
