Re: Idea Feedback: psql \h misses -> Offers Links?

On Fri, Apr 19, 2024 at 10:14 AM Euler Taveira wrote: > On Wed, Apr 17, 2024, at 2:47 PM, Kirk Wolak wrote: > > ... > > This is Question 1: Do others see the potential value here? > > > Yes. However, I expect an exact and direct answer. There will be cases &

Re: Idea Feedback: psql \h misses -> Offers Links?

On Thu, Apr 18, 2024 at 2:37 PM Peter Eisentraut wrote: > On 17.04.24 19:47, Kirk Wolak wrote: > > *Example:* > > \h current_setting > > No help available for "current_setting". > > Try \h with no arguments to see available help. > > > > htt

Re: Oom on temp (un-analyzed table caused by JIT) V16.1 [ NOT Fixed ]

On Thu, Feb 22, 2024 at 4:49 PM Michael Banck wrote: > Hi, > > On Wed, Jan 24, 2024 at 02:50:52PM -0500, Kirk Wolak wrote: > > On Mon, Jan 22, 2024 at 1:30 AM Kirk Wolak wrote: > > > On Fri, Jan 19, 2024 at 7:03 PM Daniel Gustafsson > wrote: > > >> > O

Idea Feedback: psql \h misses -> Offers Links?

Hackers, I often use the ctrl-click on the link after getting help in psql. A great feature. Challenge, when there is no help, you don't get any link. My thought process is to add a default response that would take them to https://www.postgresql.org/search/?u=%2Fdocs%2F16%2F={TOKEN}

Re: Oom on temp (un-analyzed table caused by JIT) V16.1 [ NOT Fixed ]

On Wed, Jan 24, 2024 at 4:16 PM Thomas Munro wrote: > On Thu, Jan 25, 2024 at 8:51 AM Kirk Wolak wrote: > > getrusage(RUSAGE_SELF, ); > > memory_usage_bytes = usage.ru_maxrss * 1024; > > FWIW log_statement_stats = on shows that in the logs. See ShowUsage() > in

Re: Oom on temp (un-analyzed table caused by JIT) V16.1 [ NOT Fixed ]

On Mon, Jan 22, 2024 at 1:30 AM Kirk Wolak wrote: > On Fri, Jan 19, 2024 at 7:03 PM Daniel Gustafsson wrote: > >> > On 19 Jan 2024, at 23:09, Kirk Wolak wrote: >> >> ... >> ./configure --with-llvm >> LLVM_CONFIG=/path/to/llvm-config >>

Re: Oom on temp (un-analyzed table caused by JIT) V16.1 [Fixed Already]

On Fri, Jan 19, 2024 at 7:03 PM Daniel Gustafsson wrote: > > On 19 Jan 2024, at 23:09, Kirk Wolak wrote: > > > From a FUTURE email, I noticed pg_jit_available() and it's set to f?? > > Right, then this installation does not contain the necessary library to JIT > compi

Re: Oom on temp (un-analyzed table caused by JIT) V16.1 [Fixed Already]

On Fri, Jan 19, 2024 at 4:20 AM Laurenz Albe wrote: > On Thu, 2024-01-18 at 19:50 -0500, Kirk Wolak wrote: > > I did a little more checking and the reason I did not see the link > MIGHT be because EXPLAIN did not show a JIT attempt. > > I tried to use setting

Re: Oom on temp (un-analyzed table caused by JIT) V16.1 [Fixed Already]

On Tue, Jan 16, 2024 at 3:43 AM Daniel Gustafsson wrote: > > On 16 Jan 2024, at 02:53, Kirk Wolak wrote: > > > > On Mon, Jan 15, 2024 at 9:03 AM Daniel Gustafsson <mailto:dan...@yesql.se>> wrote: > > > On 15 Jan 2024, at 07:24, Kirk Wolak wol...@gmail.

Re: Oom on temp (un-analyzed table caused by JIT) V16.1 [Fixed Already]

On Mon, Jan 15, 2024 at 9:03 AM Daniel Gustafsson wrote: > > On 15 Jan 2024, at 07:24, Kirk Wolak wrote: > > > You have a commit [1] that MIGHT fix this. > > I have a script that recreates the problem, using random data in pg_temp. > > And a nested cursor. > &g

Re: Oom on temp (un-analyzed table caused by JIT) V16.1

On Mon, Jan 15, 2024 at 9:03 AM Daniel Gustafsson wrote: > > On 15 Jan 2024, at 07:24, Kirk Wolak wrote: > > > You have a commit [1] that MIGHT fix this. > > I have a script that recreates the problem, using random data in pg_temp. > > And a nested cursor. > &g

Oom on temp (un-analyzed table caused by JIT) V16.1

Daniel, You have a commit [1] that MIGHT fix this. I have a script that recreates the problem, using random data in pg_temp. And a nested cursor. It took me a few days to reduce this from actual code that was experiencing this. If I turn off JIT, the problem goes away. (if I don't FETCH the

Re: A tiny improvement of psql

On Tue, Dec 26, 2023 at 11:26 AM Kevin Wang wrote: > Hello hackers! > > I am an Oracle/PostgreSQL DBA, I am not a PG hacker. During my daily job, > I find a pain that should be fixed. > > As you know, we can use the UP arrow key to get the previous command to > avoid extra typing. This is a

Re: Adding SHOW CREATE TABLE

On Fri, Jun 30, 2023 at 1:56 PM Kirk Wolak wrote: > On Wed, Jun 21, 2023 at 8:52 PM Kirk Wolak wrote: > >> On Mon, Jun 5, 2023 at 7:43 AM Jelte Fennema wrote: >> >>> On Thu, 1 Jun 2023 at 18:57, Kirk Wolak wrote: >>> >> Definitely have the question

Re: Adding SHOW CREATE TABLE

On Wed, Jun 21, 2023 at 8:52 PM Kirk Wolak wrote: > On Mon, Jun 5, 2023 at 7:43 AM Jelte Fennema wrote: > >> On Thu, 1 Jun 2023 at 18:57, Kirk Wolak wrote: >> > Can this get turned into a Patch? Were you offering this code up for >> others (me?) to pull, and work

Re: Add some more corruption error codes to relcache

On Fri, Jun 16, 2023 at 9:18 AM Andrey M. Borodin wrote: > Hi hackers, > > Relcache errors from time to time detect catalog corruptions. For example, > recently I observed following: > 1. Filesystem or nvme disk zeroed out leading 160Kb of catalog index. This > type of corruption passes through

Re: Do we want a hashset type?

On Mon, Jun 26, 2023 at 4:55 PM Joel Jacobson wrote: > On Mon, Jun 26, 2023, at 13:06, jian he wrote: > > Can you try to glue the attached to the hashset data type input > > function. > > the attached will parse cstring with double quote and not. so '{1,2,3}' > > == '{"1","2","3"}'. obviously

Re: pgbnech: allow to cancel queries during benchmark

On Mon, Jun 26, 2023 at 9:46 AM Yugo NAGATA wrote: > Hello, > > This attached patch enables pgbench to cancel queries during benchmark. > > Formerly, Ctrl+C during benchmark killed pgbench immediately, but backend > processes executing long queries remained for a while. You can simply >

Re: RFC: Adding \history [options] [filename] to psql (Snippets and Shared Queries)

On Tue, Jun 13, 2023 at 1:59 AM Gurjeet Singh wrote: > On Mon, Jun 5, 2023 at 8:58 AM Kirk Wolak wrote: > > > > Everyone, > > After recently deep diving on some readline features and optimizing my > bash environment to have a static set of "snipp

Re: Adding SHOW CREATE TABLE

On Mon, Jun 5, 2023 at 7:43 AM Jelte Fennema wrote: > On Thu, 1 Jun 2023 at 18:57, Kirk Wolak wrote: > > Can this get turned into a Patch? Were you offering this code up for > others (me?) to pull, and work into a patch? > > [If I do the patch, I am not sure it gives you the

Re: Let's make PostgreSQL multi-threaded

On Tue, Jun 6, 2023 at 2:00 PM Robert Haas wrote: > > I'm also not quite convinced that there's no long-term use case for > multi-process mode. Maybe you're right and there isn't, but that > amounts to arguing that every extension in the world will be happy to > run in a multi-threaded world

RFC: Adding \history [options] [filename] to psql (Snippets and Shared Queries)

Everyone, After recently deep diving on some readline features and optimizing my bash environment to have a static set of "snippets" that I can always find... it takes just a couple of history API calls to add some interesting features for those that want them. The result of adding 3-4 such

Re: [BUG] pg_dump does not properly deal with BEGIN ATOMIC function

On Sun, Jun 4, 2023 at 1:41 PM Tom Lane wrote: > Kirk Wolak writes: > .. to strings of other lengths. So the new output (before 016107478 > fixed it) is > > pg_dump: warning: could not resolve dependency loop among these items: > pg_dump: detail: FUNCTION a_f (ID 216 OI

Re: [BUG] pg_dump does not properly deal with BEGIN ATOMIC function

On Sat, Jun 3, 2023 at 2:28 PM Tom Lane wrote: > Kirk Wolak writes: > > On Fri, Jun 2, 2023 at 8:16 AM Tom Lane wrote: > > If I comprehend the suggestion, it will label each line with a warning. > > Which implies I have 6 Warnings. > > Right, I'd fo

Re: [BUG] pg_dump does not properly deal with BEGIN ATOMIC function

On Fri, Jun 2, 2023 at 8:16 AM Tom Lane wrote: > or with -v: > > pg_dump: warning: could not resolve dependency loop among these items: > pg_dump: FUNCTION a_f (ID 218 OID 40664) > pg_dump: CONSTRAINT a_pkey (ID 4131 OID 40663) > pg_dump: POST-DATA BOUNDARY (ID 4281) > pg_dump: TABLE

Re: Adding SHOW CREATE TABLE

On Thu, Jun 1, 2023 at 4:46 PM Andrew Dunstan wrote: > On 2023-06-01 Th 16:39, Kirk Wolak wrote: > > On Thu, Jun 1, 2023 at 3:13 PM Andrew Dunstan wrote: > >> On 2023-06-01 Th 12:57, Kirk Wolak wrote: >> >> PS: It dawned on me that if pg_dump had used server si

Re: Adding SHOW CREATE TABLE

On Thu, Jun 1, 2023 at 3:13 PM Andrew Dunstan wrote: > On 2023-06-01 Th 12:57, Kirk Wolak wrote: > > PS: It dawned on me that if pg_dump had used server side code to generate > its DDL, its complexity would drop. > > Maybe, that remains to be seen. pg_dump needs to produce SQL

Re: Adding SHOW CREATE TABLE

On Thu, May 25, 2023 at 9:23 AM Jelte Fennema wrote: > On Mon, 22 May 2023 at 13:52, Andrew Dunstan wrote: > > A performant server side set of functions would be written in C and > follow the patterns in ruleutils.c. > > We have lots of DDL ruleutils in our Citus codebase: > >

Re: Should CSV parsing be stricter about mid-field quotes?

On Mon, May 22, 2023 at 12:13 PM Daniel Verite wrote: > Joel Jacobson wrote: > > > Is there a valid reason why \. is needed for COPY FROM filename? > > It seems to me it would only be necessary for the COPY FROM STDIN case, > > since files have a natural end-of-file and a known file

Re: Adding SHOW CREATE TABLE

On Fri, May 19, 2023 at 1:08 PM Andrew Dunstan wrote: > I think the ONLY place we should have this is in server side functions. > More than ten years ago I did some work in this area (see below), but it's > one of those things that have been on my ever growing personal TODO list > > See

Re: Adding SHOW CREATE TABLE

On Sat, May 20, 2023 at 2:33 PM Stephen Frost wrote: > Greetings, > > On Sat, May 20, 2023 at 13:32 David G. Johnston < > david.g.johns...@gmail.com> wrote: > >> On Sat, May 20, 2023 at 10:26 AM Stephen Frost >> wrote: >> >>> > A server function can be conveniently called from any client code.

Re: Should CSV parsing be stricter about mid-field quotes?

On Wed, May 17, 2023 at 5:47 PM Joel Jacobson wrote: > On Wed, May 17, 2023, at 19:42, Andrew Dunstan wrote: > > You can use CSV mode pretty reliably for TSV files. The trick is to use a > > quoting char that shouldn't appear, such as E'\x01' as well as setting > the > > delimiter to E'\t'. Yes,

Re: psql: Could we get "-- " prefixing on the **** QUERY **** outputs? (ECHO_HIDDEN)

c.oid::pg_catalog.regclass::pg_catalog.text; /**/ Table "public.t1" ... End Clip... -- NOTICE: there is no output between queries using ECHO_HIDDEN From e8b520941154a09b350adf73cabc18dcc0596515 Mon Sep 17 00:00:00 2001 From: Kirk Wolak Date: Wed,

Re: psql: Could we get "-- " prefixing on the **** QUERY **** outputs? (ECHO_HIDDEN)

On Mon, May 15, 2023 at 9:05 PM Kirk Wolak wrote: > On Mon, May 15, 2023 at 10:28 AM Tom Lane wrote: > >> Alvaro Herrera writes: >> > It's worth considering what will readline history do with the comment. >> > Hmmm... We could put a SPACE before the comment, th

How do I set a different language to test psql? (/**** QUERY ****/)

Team, I made the / QUERY / changes. And I found the .po files, and modified those to match. make checkworld -- worked Anyway, I have NO IDEA how I run psql in a different language. I tried gnome-language-selector, I installed Russian/Czech. I switched my entire system to Russian.

Re: Adding SHOW CREATE TABLE

On Sun, May 14, 2023 at 2:20 AM Kirk Wolak wrote: > On Sat, May 13, 2023 at 3:34 PM Jeremy Smith > wrote: > >> >> >> On Sat, May 13, 2023, 3:25 AM Kirk Wolak wrote: >> >>> Does this imply SQL SYNTAX like: >>> >>> SHOW

Re: Introduce WAIT_EVENT_EXTENSION and WAIT_EVENT_BUFFER_PIN

On Tue, May 16, 2023 at 1:14 AM Michael Paquier wrote: > On Mon, May 15, 2023 at 06:01:02PM -0700, Andres Freund wrote: > > Why those tweaks are necessary is precisely what I am asking for. > > Then the perl script generates the same structures for all the wait > event classes, with all the

pgbench: can we add a way to specify the schema to write to?

Currently, I believe that we are frowning on writing things directly to Public by default. Also, we had already taken that step in our systems. Furthermore we force Public to be the first Schema, so this restriction enforces that everything created must be assigned to the appropriate schema.

Re: psql: Could we get "-- " prefixing on the **** QUERY **** outputs? (ECHO_HIDDEN)

On Mon, May 15, 2023 at 10:28 AM Tom Lane wrote: > Alvaro Herrera writes: > > It's worth considering what will readline history do with the comment. > > As I recall, we keep /* comments */ together with the query that > > follows, but the -- comments are keep in a separate history entry. > > So

Re: psql: Could we get "-- " prefixing on the **** QUERY **** outputs? (ECHO_HIDDEN)

On Mon, May 15, 2023 at 2:37 AM Pavel Stehule wrote: > Hi > > Dne po 15. 5. 2023 8:01 uživatel Kirk Wolak napsal: > >> This would be a trivial change. Willing to do it, and push it. >> >> In effect, we have this GREAT feature: >> \set ECHO_HIDDON on >>

psql: Could we get "-- " prefixing on the **** QUERY **** outputs? (ECHO_HIDDEN)

This would be a trivial change. Willing to do it, and push it. In effect, we have this GREAT feature: \set ECHO_HIDDON on Which outputs a bunch of queries (as you all know). But somehow nobody thought that a user might want to paste ALL of the queries into their query editor, or even into

PSQL Should \sv & \ev work with materialized views?

Personally I would appreciate it if \sv actually showed you the DDL. Oftentimes I will \ev something to review it, with syntax highlighting. Obviously this won't go in until V17, but looking at other tab-completion fixes. This should not be that difficult. Just looking for feedback. Admittedly

Re: psql tests hangs

On Fri, May 12, 2023 at 2:40 AM Pavel Stehule wrote: > pá 12. 5. 2023 v 8:20 odesílatel Kirk Wolak napsal: > >> On Fri, May 12, 2023 at 1:46 AM Pavel Stehule >> wrote: >> >>> pá 12. 5. 2023 v 6:50 odesílatel Kirk Wolak napsal: >>> >>>

Re: psql tests hangs

On Fri, May 12, 2023 at 1:46 AM Pavel Stehule wrote: > pá 12. 5. 2023 v 6:50 odesílatel Kirk Wolak napsal: > >> On Fri, May 12, 2023 at 12:14 AM Tom Lane wrote: >> >>> Kirk Wolak writes: >>> > Did you try the print statement that Andrey asked Pavel to

Re: psql tests hangs

On Fri, May 12, 2023 at 12:14 AM Tom Lane wrote: > Kirk Wolak writes: > > Did you try the print statement that Andrey asked Pavel to try? > > Yeah, and I get exactly the results I expect: > > Your results MATCHED Pavels (Hmm). Piping ONE of those into psql should fa

Re: psql tests hangs

On Thu, May 11, 2023 at 8:08 PM Tom Lane wrote: > Kirk Wolak writes: > > Can you change the 0.01 to just 1 or 0? > > I assume it will work then! (and better than a full removal)? > > IMO the point of that test is largely to exercise this locale-dependent > behavio

Re: psql tests hangs

On Wed, May 10, 2023 at 12:59 AM Pavel Stehule wrote: > Hi > > When I remove this test, then all tests passed > > diff --git a/src/bin/psql/t/001_basic.pl b/src/bin/psql/t/001_basic.pl > index 596746de17..631a1a7335 100644 > --- a/src/bin/psql/t/001_basic.pl > +++ b/src/bin/psql/t/001_basic.pl >

Re: v16 regression - wrong query results with LEFT JOINs + join removal

On Thu, May 11, 2023 at 11:50 AM Robert Haas wrote: > On Thu, May 11, 2023 at 10:14 AM Robert Haas > wrote: > > Ouch, so we've had a known queries-returning-wrong-answers bug for > > more than two months. That's not great. I'll try to find time today to > > check whether the patches on that

Re: Discussion: psql \et -> edit the trigger function

On Wed, May 10, 2023 at 1:33 PM Tom Lane wrote: > I wrote: > > Hmm, I wonder how useful that's really going to be, considering > > that trigger names aren't unique across tables. Wouldn't it > > need to be more like "\et table-name trigger-name"? > > Different line of thought: \et seems awfully

Re: psql tests hangs

On Thu, May 11, 2023 at 3:06 PM Pavel Stehule wrote: > > > čt 11. 5. 2023 v 20:44 odesílatel Tom Lane napsal: > >> Pavel Stehule writes: >> > When I remove this test, then all tests passed >> >> This works fine for me on Fedora 37: >> > > I have Fedora 38 > >> >> $ cd src/bin/psql >> $

Re: Discussion: psql \et -> edit the trigger function

On Wed, May 10, 2023 at 12:20 PM Pavel Stehule wrote: > Hi > > st 10. 5. 2023 v 17:33 odesílatel Kirk Wolak napsal: > >> We already have >> \ef >> \ev >> >> The use case here is simply that it saves me from: >> \d >> [scroll through all

Discussion: psql \et -> edit the trigger function

We already have \ef \ev The use case here is simply that it saves me from: \d [scroll through all the fields] [often scroll right] select function name \ef [paste function name] and tab completion is much narrower When doing conversions and reviews all of this stuff has to be reviewed.

Re: enhancing plpgsql debug api - hooks on statements errors and function errors

On Tue, Apr 25, 2023 at 11:33 AM Pavel Stehule wrote: > Hi > út 25. 4. 2023 v 10:27 odesílatel Pavel Stehule > napsal: > >> Hi >> >> When I implemented profiler and coverage check to plpgsql_check I had to >> write a lot of hard maintaining code related to corect finishing some >> operations

Re: Commitfest 2023-03 starting tomorrow!

On Fri, Apr 7, 2023 at 6:29 PM Tom Lane wrote: > Kirk Wolak writes: > > The %T added to the PSQL Prompt is about 5 lines of code. Reviewed and > > Ready to commit. > > That could knock one more off really quickly :-) > > I'm still objecting to it, fo

Re: Commitfest 2023-03 starting tomorrow!

On Fri, Apr 7, 2023 at 10:21 AM Greg Stark wrote: > As announced on this list feature freeze is at 00:00 April 8 AoE. > That's less than 24 hours away. If you need to set your watches to AoE > timezone it's currently: > > $ TZ=AOE+12 date > Fri 07 Apr 2023 02:05:50 AM AOE > > As we stand we

Re: Schema variables - new implementation for Postgres 15

On Thu, Mar 30, 2023 at 4:06 AM Pavel Stehule wrote: > Hi > > ne 26. 3. 2023 v 19:44 odesílatel Dmitry Dolgov <9erthali...@gmail.com> > napsal: > >> > On Fri, Mar 24, 2023 at 08:04:08AM +0100, Pavel Stehule wrote: >> > čt 23. 3. 2023 v 19:54 odesílatel Pavel Stehule < >> pavel.steh...@gmail.com>

Re: Schema variables - new implementation for Postgres 15

On Wed, Apr 5, 2023 at 1:58 PM Pavel Stehule wrote: > > > st 5. 4. 2023 v 19:20 odesílatel Greg Stark napsal: > >> On Sun, 26 Mar 2023 at 07:34, Julien Rouhaud wrote: >> > >> > This feature can significantly increase log size, so it's disabled by >> default. >> > For testing or development

Re: [PATCH] Add function to_oct

On Thu, Feb 23, 2023 at 6:32 AM Peter Eisentraut < peter.eisentr...@enterprisedb.com> wrote: > On 20.12.22 23:08, Eric Radman wrote: > > This patch is a new function based on the implementation of to_hex(int). > > > > Since support for octal integer literals was added, to_oct(int) allows > >

Re: psql \watch 2nd argument: iteration count

On Fri, Mar 24, 2023 at 10:32 PM Andrey Borodin wrote: > On Thu, Mar 23, 2023 at 10:15 PM Yugo NAGATA wrote: > > > > Here is my review on the v9 patch. > > > > + /* we do not prevent numerous names iterations like > i=1 i=1 i=1 */ > > + have_sleep = true; > >

Re: SELECT INTO without columns or star

On Fri, Mar 31, 2023 at 11:26 AM Tom Lane wrote: > "David G. Johnston" writes: > > On Fri, Mar 31, 2023 at 8:10 AM Zhang Mingli > wrote: > >> When I exec a sql SELECT INTO without columns or * by mistake, it > succeeds: > > > Yes, a table may have zero columns by design. > > Yup, we've allowed

Re: zstd compression for pg_dump

On Tue, Mar 28, 2023 at 12:23 PM Tomas Vondra wrote: > On 3/27/23 19:28, Justin Pryzby wrote: > > On Fri, Mar 17, 2023 at 03:43:31AM +0100, Tomas Vondra wrote: > >> On 3/16/23 05:50, Justin Pryzby wrote: > >>> On Fri, Mar 10, 2023 at 12:48:13PM -0800, Jacob Champion wrote: > On Wed, Mar 8,

Re: possible proposal plpgsql GET DIAGNOSTICS oid = PG_ROUTINE_OID

On Sun, Mar 26, 2023 at 5:37 PM Kirk Wolak wrote: > On Wed, Feb 8, 2023 at 10:56 AM Kirk Wolak wrote: > >> On Wed, Feb 8, 2023 at 3:08 AM Pavel Stehule >> wrote: >> >>> hi >>> >>> st 8. 2. 2023 v 7:33 odesílatel Julien Rouhaud >>&g

Re: Documentation Not Compiling (http://docbook... not https:.//...)

On Sun, Mar 26, 2023 at 9:12 PM Kirk Wolak wrote: > Andres, > Apologies to pick on you directly. > But it appears that sites are refusing HTTP requests, > and it's affecting compilation of docs in a new configuration. > > I was surprised to see NON-HTTPS references i

Documentation Not Compiling (http://docbook... not https:.//...)

Andres, Apologies to pick on you directly. But it appears that sites are refusing HTTP requests, and it's affecting compilation of docs in a new configuration. I was surprised to see NON-HTTPS references in 2023, tbh... I cannot even curl these references. Maybe I am missing a simple

Re: possible proposal plpgsql GET DIAGNOSTICS oid = PG_ROUTINE_OID

On Wed, Feb 8, 2023 at 10:56 AM Kirk Wolak wrote: > On Wed, Feb 8, 2023 at 3:08 AM Pavel Stehule > wrote: > >> hi >> >> st 8. 2. 2023 v 7:33 odesílatel Julien Rouhaud >> napsal: >> >>> On Tue, Feb 07, 2023 at 08:48:22PM +0100, Pavel

Re: Operation log for major operations

On Thu, Mar 2, 2023 at 4:09 PM Dmitry Koval wrote: > I'll try to expand my explanation. > I fully understand and accept the arguments about "limited sense to go > into the control file" and "about recording *anything* in the control > file". This is totally correct for vanilla. > But vendors

Re: proposal: psql: show current user in prompt

On Sat, Feb 4, 2023 at 3:33 PM Pavel Stehule wrote: > Hi > > pá 3. 2. 2023 v 21:43 odesílatel Pavel Stehule > napsal: > >> >> >> pá 3. 2. 2023 v 21:21 odesílatel Tom Lane napsal: >> >>> Pavel Stehule writes: >>> > Both patches are very simple - and they use almost already prepared >>> >

Re: Proposal: %T Prompt parameter for psql for current time (like Oracle has)

On Thu, Mar 2, 2023 at 9:56 AM Laurenz Albe wrote: > On Wed, 2023-03-01 at 11:13 -0500, Kirk Wolak wrote: > > Thanks, corrected, and confirmed Unix line endings. > > The patch builds fine and works as intended. > > I leave it to the committers to decide whether the patch

Re: Proposal: %T Prompt parameter for psql for current time (like Oracle has)

On Wed, Mar 1, 2023 at 11:55 AM Jim Jones wrote: > On 01.03.23 17:13, Kirk Wolak wrote: > > Thanks, corrected, and confirmed Unix line endings. > FWIW, the simplest way to test it is with this command (I usually get it > wrong on the first guess) > > \set PROMPT1 %T

Re: Proposal: %T Prompt parameter for psql for current time (like Oracle has)

On Wed, Mar 1, 2023 at 4:41 AM Jim Jones wrote: > On 01.03.23 01:59, Kirk Wolak wrote: > > I cannot get the last email to show up for the commitfest. > > This is version 2 of the original patch. [1] > > Thanks Jim! > > > > [1] > https://postgr.

Proposal: %T Prompt parameter for psql for current time (like Oracle has)

:MI:SS no other options available by design! Author: Kirk Wolak Reviewed-By: Andrey Borodin Reviewed-By: Nikolay Samokhvalov Thread: https://postgr.es/m/CACLU5mSRwHr_8z%3DenMj-nXF1tmC7%2BJn5heZQNiKuLyxYUtL2fg%40mail.gmail.com --- doc/src/sgml/ref/psql-ref.sgml | 9 + src/bin/psql

Re: Proposal: %T Prompt parameter for psql for current time (like Oracle has)

On Thu, Feb 23, 2023 at 2:05 PM Kirk Wolak wrote: > On Thu, Feb 23, 2023 at 9:52 AM Tom Lane wrote: > >> Heikki Linnakangas writes: >> > On 23/02/2023 13:20, Peter Eisentraut wrote: >> >> If you don't have \timing turned on before the query starts, psql

Re: Proposal: :SQL_EXEC_TIME (like :ROW_COUNT) Variable (psql)

On Sun, Feb 26, 2023 at 11:45 PM Pavel Stehule wrote: > po 27. 2. 2023 v 5:08 odesílatel Kirk Wolak napsal: > >> On Fri, Feb 24, 2023 at 10:56 PM Kirk Wolak wrote: >> >>> On Fri, Feb 24, 2023 at 2:11 AM Gurjeet Singh wrote: >>> >>>> O

Re: Proposal: :SQL_EXEC_TIME (like :ROW_COUNT) Variable (psql)

On Fri, Feb 24, 2023 at 10:56 PM Kirk Wolak wrote: > On Fri, Feb 24, 2023 at 2:11 AM Gurjeet Singh wrote: > >> On Thu, Feb 23, 2023 at 8:42 PM Kirk Wolak wrote: >> > ... > > I think like ROW_COUNT, it should not change because of internal >> commands. >

Re: Proposal: :SQL_EXEC_TIME (like :ROW_COUNT) Variable (psql)

On Fri, Feb 24, 2023 at 7:09 AM Jim Jones wrote: > On 23.02.23 20:55, Kirk Wolak wrote: > > Everyone, > ... SQL_EXEC_TIME > > I think like ROW_COUNT, it should not change because of internal > > commands. > > So, you guys +1 this thing, give additional comments.

Re: Proposal: :SQL_EXEC_TIME (like :ROW_COUNT) Variable (psql)

On Fri, Feb 24, 2023 at 2:11 AM Gurjeet Singh wrote: > On Thu, Feb 23, 2023 at 8:42 PM Kirk Wolak wrote: > > I love that my proposal for %T in the prompt, triggered some great > conversations. > > > > This is not instead of that. That lets me run a query and

Proposal: :SQL_EXEC_TIME (like :ROW_COUNT) Variable (psql)

Everyone, I love that my proposal for %T in the prompt, triggered some great conversations. This is not instead of that. That lets me run a query and come back HOURS later, and know it finished before 7PM like it was supposed to! This feature is simple. We forget to set \timing on... We

Re: Proposal: %T Prompt parameter for psql for current time (like Oracle has)

my most used. A small frustration, felt regularly was the motive. Regards, Kirk PS: If I am supposed to edit the subject to say there is a patch here, I did not know PPS: I appreciate ANY and ALL feedback... This is how we learn! From eaf6d05028052a3ccaa8d980953ac4fd75255250 Mon Sep 17 00:00:00 2

Re: Proposal: %T Prompt parameter for psql for current time (like Oracle has)

On Thu, Feb 23, 2023 at 1:16 PM Maciek Sakrejda wrote: > On Thu, Feb 23, 2023, 09:55 Nikolay Samokhvalov > wrote: > >> On Thu, Feb 23, 2023 at 9:05 AM Maciek Sakrejda >> wrote: >> >>> I think Heikki's solution is probably more practical since (1) .. >> >> >> Note that these ideas target two

Re: Proposal: %T Prompt parameter for psql for current time (like Oracle has)

On Wed, Feb 22, 2023 at 1:14 PM Heikki Linnakangas wrote: > On 22/02/2023 19:59, Nikolay Samokhvalov wrote: > > On Wed, Feb 22, 2023 at 9:55 AM Tom Lane > > wrote: > > > > On the whole I'd rather not eat more of the limited namespace for > > psql prompt codes

Re: Proposal: %T Prompt parameter for psql for current time (like Oracle has)

On Wed, Feb 22, 2023 at 12:55 PM Tom Lane wrote: > Kirk Wolak writes: > > Proposal: Simply add the %T (PROMPT variable) to output the current time > > (HH24:MI:SS) into the prompt. > > I'm not really convinced that %`date` isn't a usable solution for this, > especi

Proposal: %T Prompt parameter for psql for current time (like Oracle has)

Proposal: Simply add the %T (PROMPT variable) to output the current time (HH24:MI:SS) into the prompt. This has been in sqlplus since I can remember, and I find it really useful when I forgot to time something, or to review for Time spent on a problem, or for how old my session is... I am

Re: possible proposal plpgsql GET DIAGNOSTICS oid = PG_ROUTINE_OID

On Wed, Feb 8, 2023 at 3:08 AM Pavel Stehule wrote: > hi > > st 8. 2. 2023 v 7:33 odesílatel Julien Rouhaud > napsal: > >> On Tue, Feb 07, 2023 at 08:48:22PM +0100, Pavel Stehule wrote: >> > >> > GET DIAGNOSTICS _oid = PG_ROUTINE_OID; >> > RAISE NOTICE '... % ... %', _oid, _oid::regproc::text;

Re: possible proposal plpgsql GET DIAGNOSTICS oid = PG_ROUTINE_OID

On Tue, Feb 7, 2023 at 2:49 PM Pavel Stehule wrote: > Hi > > I have a question about the possibility of simply getting the name of the > currently executed function. The reason for this request is simplification > of writing debug messages. > > GET DIAGNOSTICS _oid = PG_ROUTINE_OID; > RAISE

Help running 010_tab_completion.pl on windows

I have psql working with readline (roughly) in windows 10! in my attempt to test it... >> 1..0 # SKIP IO::Pty is needed to run this test I would like to run these tests to see how far off I am... (Randomly typing sql and squealing like a child has its limits) I have built this using VS 2022

Re: PL/pgSQL cursors should get generated portal names by default

On Mon, Nov 7, 2022 at 11:10 AM Jan Wieck wrote: > On 11/4/22 19:46, Tom Lane wrote: > > Jan Wieck writes: > >> I need to do some testing on this. I seem to recall that the naming was > >> originally done because a reference cursor is basically a named cursor > >> that can be handed around