On 3/18/25 23:41, Sebastien Flaesch wrote:
You are right Adrian, I did not search properly I found the header file
here:
sf@toro:/opt3/dbs/pgs/17.4$ ls -l
include/postgresql/server/catalog/pg_type_d.h
-rw-r--r-- 1 sf sf 9672 Mar 13 17:05
include/postgresql/server/catalog/pg_type_d.h
I was n
Igor Korot writes:
> On Sat, Mar 22, 2025, 8:58 PM David G. Johnston
> wrote:
>> Then read the psql docs. Your version has \if and you’ll find server
>> version listed as the available client variables.
> I was hoping for something like
> If server_version >= X:
> CREATE OR REPLACE TRIGGE
Hi, David,
On Sat, Mar 22, 2025, 8:58 PM David G. Johnston
wrote:
> On Saturday, March 22, 2025, Igor Korot wrote:
>
>>
>>
>>> Is it actually running in psql?
>>>
>>
>> Yes, i run "psql - d draft -a -f
>>
>
> Then read the psql docs. Your version has \if and you’ll find server
> version liste
On Saturday, March 22, 2025, Igor Korot wrote:
>
>
>> Is it actually running in psql?
>>
>
> Yes, i run "psql - d draft -a -f
>
Then read the psql docs. Your version has \if and you’ll find server
version listed as the available client variables.
David J.
Hi, Adrian,
On Sat, Mar 22, 2025, 7:42 PM Adrian Klaver
wrote:
> On 3/22/25 17:31, Igor Korot wrote:
> > Hi, All,
> > I have a big script that populated the DB for me.
>
> The language used for the script?
>
What do you mean?
Its just a text file with bunch of create table/insert into
> Is it
Christophe Pettus writes:
> That's an interesting question. It appears to be a no-op, although a quick
> scan of the code doesn't reveal why. Here's an illustrative test case:
This test case would be less confusing if the outer handler did
RAISE NOTICE 'in outer exception handler: %', sqler
Hi, All,
I have a big script that populated the DB for me.
I made it based on the latest available version.
However, i have version 13 installed on my Linux box and so trying to
execute "CREATE OR REPLACE TRIGGER..." will fail.
Is there a way to determine the server version from such a script?
Adrian Klaver writes:
> On 3/22/25 17:31, Igor Korot wrote:
>> Is there a way to determine the server version from such a script?
> show server_version_num;
psql already populates its SERVER_VERSION_NUM variable from that
for you.
regards, tom lane
> On Mar 22, 2025, at 21:37, Kevin Stephenson wrote:
>
> Christophe and Tom, thank you for your responses, but I'm still a bit
> confused. In my original email, the Test 2 case is allowing a ROLLBACK in the
> EXCEPTION clause without throwing an error. Is it a NOP ROLLBACK being
> applied t
Kevin Stephenson writes:
> Christophe and Tom, thank you for your responses, but I'm still a bit
> confused. In my original email, the Test 2 case is allowing a ROLLBACK in the
> EXCEPTION clause without throwing an error. Is it a NOP ROLLBACK being
> applied to an aborted subTX, a real full RO
Christophe and Tom, thank you for your responses, but I'm still a bit confused.
In my original email, the Test 2 case is allowing a ROLLBACK in the EXCEPTION
clause without throwing an error. Is it a NOP ROLLBACK being applied to an
aborted subTX, a real full ROLLBACK, or something else? Please
Senthilnathan M writes:
> I came across this extension which shows all the plans considered by the
> optimizer: https://github.com/misachi/pg_all_plans
> Is there a way we can get this information directly instead of using an
> extension? If not, does it make sense to add native support?
Th
Hi all,
I came across this extension which shows all the plans considered by the
optimizer: https://github.com/misachi/pg_all_plans
Is there a way we can get this information directly instead of using an
extension? If not, does it make sense to add native support?
Please feel free to redir
Christophe Pettus writes:
> A procedure cannot issue top-level transaction control statements from within
> an exception block, and attempting to do so raises the error you saw. This
> includes procedures that are called from within an exception block.
Yeah. Postgres doesn't have autonomous t
David,
That said, I am curious as to the education flow a developer, not linking in
this specific header to their code, would go through in order to learn about
type OIDs and make use of them in their project. Maybe that flow is good,
maybe not. It's a rare flow and there are many things to do
Hello,
> On Mar 22, 2025, at 08:38, Kevin Stephenson wrote:
> • When a top-level stored procedure is called it implicitly creates a TX
> if there is no current TX.
> • When a BEGIN/EXCEPTION block is used it implicitly creates a subTX for
> that block.
These statements are correct.
>
Hi all,
I'm assessing the feasibility of implementing a full featured "DB as API"
concept in PostgreSQL (PG) and have run across an apparent inconsistency in the
transaction (TX) handling behavior with nested stored procedures. This apparent
inconsistency is present in both 16.4 and 17.4 runnin
17 matches
Mail list logo
