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 <t...@sss.pgh.pa.us> wrote: > "David G. Johnston" <david.g.johns...@gmail.com> writes: > > On Sat, Apr 17, 2021 at 10:58 AM Vladimír Houba ml. <v.ho...@gmail.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.
