Re: feature request ctid cast / sql exception

I use ctid as a row identifier within a transaction in a Java application.
To obtain the row ctid I either have to

- cast it to text and store it as String
- cast it to string, then convert it to a bigint using UDF which is
inefficient

I wish I could just cast ctid to bigint and store it as a primitive long
type.

Regarding the exception throwing function it makes good sense for example
in case blocks when you encouter unexpected value.
IMHO "one fits all" solution may be making a raise function with the same
syntax as raise statement in plpgsql.

RAISE([ level ] 'format' [, expression [, ... ]] [ USING option =
expression [, ... ] ])
RAISE([ level ] condition_name [ USING option = expression [, ... ] ])
RAISE([ level ] SQLSTATE 'sqlstate' [ USING option = expression [, ... ] ])
RAISE([ level ] USING option = expression [, ... ])
RAISE()

On Sat, Apr 17, 2021 at 9:46 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> "David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> > On Sat, Apr 17, 2021 at 10:58 AM Vladimír Houba ml. <v(dot)houba(at)gmail(dot)com>
> > wrote:
> >> Another nice feature would be a function that can be called from a sql
> >> statement and would throw an exception when executed.
>
> > An assertion-related extension in core would be welcomed.
>
> This has been suggested before, but as soon as you start looking
> at the details you find that it's really hard to get a one-size-fits-all
> definition that's any simpler than the existing plpgsql RAISE
> functionality. Different people have different ideas about how
> much decoration they want around the message. So, if 10% of the
> world agrees with your choices and the other 90% keeps on using
> a custom plpgsql function to do it their way, you haven't really
> improved matters much. OTOH a 90% solution might be interesting to
> incorporate in core, but nobody's demonstrated that one exists.
>
> regards, tom lane
>

--
S pozdravom
Vladimír Houba ml.