Pandas version checks

• I have checked that this issue has not already been reported.

• I have confirmed this bug exists on thelatest version of pandas.

• I have confirmed this bug exists on themain branch of pandas.

Reproducible Example

ThisexamplerequiresanOracle19cdatabaseengine=sqlalchemy.create_engine('oracle+oracledb://...',echo=True)con=engine.connect()c.execute(text('''CREATE PRIVATE TEMPORARY TABLE ORA$PTT_TEMP (  a INT) ON COMMIT DROP DEFINITION'''))pd.DataFrame({'a': [1]}).to_sql('ORA$PTT_TEMP',engine)-05-0911:10:00,967INFOsqlalchemy.engine.EngineSELECTtables_and_views.table_nameFROM (SELECTa_tables.table_nameAStable_name,a_tables.ownerASownerFROMall_tablesa_tablesUNIONALLSELECTa_views.view_nameAStable_name,a_views.ownerASownerFROMall_viewsa_views)tables_and_viewsWHEREtables_and_views.table_name= :table_nameANDtables_and_views.owner= :owner2025-05-0911:10:00,967INFOsqlalchemy.engine.Engine [cachedsince533.2sago] {'table_name':'ORA$PTT_TEMP','owner':'...'}2025-05-0911:10:00,993INFOsqlalchemy.engine.EngineCREATETABLEORA$PTT_TEMP (curve_idINT)DatabaseError: (oracledb.exceptions.DatabaseError)ORA-32463:cannotcreateanobjectwithanamematchingprivatetemporarytableprefix

Issue Description

Hello Pandas!
I am trying to use DataFrame.to_sql with Oracle "PRIVATE TEMPORARY" tables.
The catch is that these tables for whatever reason cannot be detected with the inspector.has_table() method, so pandas is trying to create the table, and then fails.

The issue is quite annoying, because the error is in thepandas.SQLDatabase.prep_table() method, which is called unconditionally in thepandas.SQLDatabase.to_sql(), and there is no way to override it with a custom "method: callable" parameter topandas.DataFrame.to_sql().

Though one could argue that this is a bug in the SQLAlchemy Oracle dialect, rather than Pandas. But IMHO it should be possible to skip the table check and creation altogether in thepandas.DataFrame.to_sql() call.
It looks like it would be easy to add askip_table_creation: bool = False argument to theto_sql() method, that would just skip the prep_table call in SQLDatabase.to_sql().
The downside would be that pandas would not have the reflected information about target database types, but this could potentially be solved by passing a customsqlalchemy.Table object?

What do you think about this? Is this a direction that Pandas would like to go in, or do you think about the.to_sql() method more as a handy feature for ad-hoc operations, that should not be used much in production? Do you think it is better to write my own insert methods and not rely on.to_sql() for production use?

Expected Behavior

I expect that it will not try to create a table if it exists, or an option to skip table creation if I know that it does not exist.

Installed Versions

INSTALLED VERSIONS

commit :0691c5c
python : 3.11.3
python-bits : 64
OS : Darwin
OS-release : 24.4.0
Version : Darwin Kernel Version 24.4.0: Fri Apr 11 18:33:47 PDT 2025; root:xnu-11417.101.15~117/RELEASE_ARM64_T6000
machine : arm64
processor : arm
byteorder : little
LC_ALL : None
LANG : None
LOCALE : None.UTF-8

pandas : 2.2.3
numpy : 1.26.4
pytz : 2024.2
dateutil : 2.8.2
pip : 24.0
Cython : None
sphinx : None
IPython : 8.21.0
adbc-driver-postgresql: None
adbc-driver-sqlite : None
bs4 : 4.12.3
blosc : None
bottleneck : None
dataframe-api-compat : None
fastparquet : None
fsspec : 2024.3.1
html5lib : 1.1
hypothesis : None
gcsfs : None
jinja2 : 3.1.3
lxml.etree : 5.1.0
matplotlib : 3.10.1
numba : None
numexpr : None
odfpy : None
openpyxl : 3.1.2
pandas_gbq : None
psycopg2 : 2.9.9
pymysql : 1.4.6
pyarrow : 15.0.0
pyreadstat : None
pytest : 8.3.3
python-calamine : None
pyxlsb : None
s3fs : None
scipy : None
sqlalchemy : 2.0.40
tables : None
tabulate : 0.9.0
xarray : None
xlrd : None
xlsxwriter : None
zstandard : None
tzdata : 2024.1
qtpy : None
pyqt5 : None