Hi
> So it's a two step process for me currently because of this, I would love
> if there was a better way to handle
> this type of work though, because my plpgsql functions using exception
> blocks are not exactly great
> for performance.
>
Probably we can for some important buildin types write
> What would you actually do with it?
I am one of the users of these do-it-yourself functions, and I use them in
my ETL pipelines heavily.
For me, data gets loaded into a staging table, all columns text, and I run
a whole bunch of validation queries
on the data prior to it moving to the next sta
=?UTF-8?Q?Micha=C5=82_Wadas?= writes:
> Currently there is no way to check if CAST will succeed.
> Therefore I propose adding new function: is_castable
> SELECT is_castable('foo' as time) // false
What would you actually do with it?
> Similar features are implemented in:
> - SQL Server (as TRY_
Hi
pá 3. 4. 2020 v 13:45 odesílatel Michał Wadas
napsal:
> Currently there is no way to check if CAST will succeed.
>
> Therefore I propose adding new function: is_castable
>
> SELECT is_castable('foo' as time) // false
> SELECT is_castable('123' as numeric) // true
> SELECT is_castable(1.5 as i
Currently there is no way to check if CAST will succeed.
Therefore I propose adding new function: is_castable
SELECT is_castable('foo' as time) // false
SELECT is_castable('123' as numeric) // true
SELECT is_castable(1.5 as int) // true
SELECT is_castable('1.5' as int) // false
Many users write
