Re: Error-safe user functions

On Fri, Dec 2, 2022 at 1:46 PM Tom Lane wrote: > Corey Huinker writes: > > I'm still working on organizing my patch, but it grew out of a desire to > do > > this: > > CAST(value AS TypeName DEFAULT expr) > > This is a thing that exists in other forms in oth

Re: Error-safe user functions

> > I think there are just a couple of loose ends here: > > 1. Bikeshedding on my name choices is welcome. I know Robert is > dissatisfied with "ereturn", but I'm content with that so I didn't > change it here. > 1. details_please => include_error_data as this hints the reader directly to the st

Re: Make ON_ERROR_STOP stop on shell script failure

On Tue, Nov 22, 2022 at 6:16 PM Matheus Alcantara wrote: > --- Original Message --- > On Tuesday, November 22nd, 2022 at 20:10, bt22nakamorit < > bt22nakamo...@oss.nttdata.com> wrote: > > > > There was a mistake in the error message for \! so I updated the patch. > > > > Best, > > Tatsuhi

Re: Add SHELL_EXIT_CODE to psql

Rebased. Still waiting on feedback before working on documentation. On Fri, Nov 4, 2022 at 5:23 AM Corey Huinker wrote: > Oops, that sample output was from a previous run, should have been: > > -- SHELL_EXIT_CODE is undefined > \echo :SHELL_EXIT_CODE > :SHELL_EXIT_CODE > -

Re: Error-safe user functions

On Mon, Dec 5, 2022 at 11:36 AM Andrew Dunstan wrote: > > On 2022-12-05 Mo 11:20, Robert Haas wrote: > > On Mon, Dec 5, 2022 at 11:09 AM Tom Lane wrote: > >> Robert Haas writes: > >>> On Sat, Dec 3, 2022 at 10:57 PM Corey Huinker > wrote: > >>&g

Re: Error-safe user functions

On Mon, Dec 5, 2022 at 1:00 PM Tom Lane wrote: > Andrew Dunstan writes: > > Wait a minute! Oh, no, sorry, as you were, 'errsave' is fine. > > Seems like everybody's okay with errsave. I'll make a v2 in a > little bit. I'd like to try updating array_in and/or record_in > just to verify that in

Re: ANY_VALUE aggregate

On Mon, Dec 5, 2022 at 12:57 PM David G. Johnston < david.g.johns...@gmail.com> wrote: > On Mon, Dec 5, 2022 at 7:57 AM Vik Fearing > wrote: > >> The SQL:2023 Standard defines a new aggregate named ANY_VALUE. It >> returns an implementation-dependent (i.e. non-deterministic) value from >> the ro

Re: Error-safe user functions

On Tue, Dec 6, 2022 at 6:46 AM Andrew Dunstan wrote: > > On 2022-12-05 Mo 20:06, Tom Lane wrote: > > Andres Freund writes: > > > >> But perhaps it's even worth having such a function properly exposed: > >> It's not at all rare to parse text data during ETL and quite often > >> erroring out fatal

Re: Error-safe user functions

On Wed, Dec 7, 2022 at 9:20 AM Tom Lane wrote: > Andrew Dunstan writes: > > Perhaps we should add a type in the regress library that will never have > > a safe input function, so we can test that the mechanism works as > > expected in that case even after we adjust all the core data types' > > i

Re: Error-safe user functions

On Wed, Dec 7, 2022 at 12:17 PM Tom Lane wrote: > Corey Huinker writes: > > In my attempt to implement CAST...DEFAULT, I noticed that I immediately > > needed an > > OidInputFunctionCallSafe, which was trivial but maybe something we want > to > > add to the infra

Re: Error-safe user functions

On Fri, Dec 9, 2022 at 11:17 AM Amul Sul wrote: > On Fri, Dec 9, 2022 at 9:08 PM Andrew Dunstan wrote: > > > > > > On 2022-12-09 Fr 10:16, Tom Lane wrote: > > > Andrew Dunstan writes: > > >> On 2022-12-08 Th 21:59, Tom Lane wrote: > > >>> Yeah, I was planning to take a look at that before walki

Re: Error-safe user functions

On Sat, Dec 10, 2022 at 9:20 AM Tom Lane wrote: > Alvaro Herrera writes: > > On 2022-Dec-09, Tom Lane wrote: > >> ... So I think it might be > >> okay to say "if you want soft error treatment for a domain, > >> make sure its check constraints don't throw errors". > > > I think that's fine. If

Re: Add SHELL_EXIT_CODE to psql

On Fri, Jan 20, 2023 at 8:54 AM Robert Haas wrote: > On Wed, Jan 4, 2023 at 2:09 AM Corey Huinker > wrote: > > 2. There are now two psql variables, SHELL_EXIT_CODE, which has the > return code, and SHELL_ERROR, which is a true/false flag based on whether > the exit code

Re: Add SHELL_EXIT_CODE to psql

On Mon, Jan 23, 2023 at 2:53 PM Robert Haas wrote: > On Mon, Jan 23, 2023 at 1:59 PM Corey Huinker > wrote: > > SHELL_ERROR is helpful in that it is a ready-made boolean that works for > \if tests in the same way that ERROR is set to true any time SQLSTATE is > nonzero. We don

Re: Add SHELL_EXIT_CODE to psql

> > Thanks! But CF bot still not happy. I think, we should address issues from > here https://cirrus-ci.com/task/5391002618298368 > Sure enough, exit codes are shell dependent...adjusted the tests to reflect that. From 237b892e5efe739bc8e75d4af30140520d445491 Mon Sep 17 00:00:00 2001 From: coreyhu

Add n_tup_newpage_upd to pg_stat table views

This patch adds the n_tup_newpage_upd to all the table stat views. Just as we currently track HOT updates, it should be beneficial to track updates where the new tuple cannot fit on the existing page and must go to a different one. Hopefully this can give users some insight as to whether their cu

Re: Add n_tup_newpage_upd to pg_stat table views

On Fri, Jan 27, 2023 at 6:55 PM Andres Freund wrote: > Hi, > > On 2023-01-27 18:23:39 -0500, Corey Huinker wrote: > > This patch adds the n_tup_newpage_upd to all the table stat views. > > > > Just as we currently track HOT updates, it should be beneficial to trac

Re: Add SHELL_EXIT_CODE to psql

> > > Unfortunately, there is a fail in FreeBSD > https://cirrus-ci.com/task/6466749487382528 > > Maybe, this patch is need to be rebased? > > That failure is in postgres_fdw, which this code doesn't touch. I'm not able to get to /tmp/cirrus-ci-build/build/testrun/postgres_fdw-running/regress/reg

Re: transition tables and UPDATE

> > > even uglier than what I already had. So yeah, I think it might be > useful if we had a way to inject a counter or something in there. > > This came up for me when I was experimenting with making the referential integrity triggers fire on statements rather than rows. Doing so has the potentia

Re: Remove some useless casts to (void *)

On Thu, Feb 2, 2023 at 5:22 PM Peter Eisentraut < peter.eisentr...@enterprisedb.com> wrote: > I have found that in some corners of the code some calls to standard C > functions are decorated with casts to (void *) for no reason, and this > code pattern then gets copied around. I have gone through

Re: proposal: psql: psql variable BACKEND_PID

On Fri, Feb 3, 2023 at 5:42 AM Pavel Stehule wrote: > Hi > > We can simply allow an access to backend process id thru psql variable. I > propose the name "BACKEND_PID". The advantages of usage are simple > accessibility by command \set, and less typing then using function > pg_backend_pid, becaus

Re: proposal: psql: show current user in prompt

On Fri, Feb 3, 2023 at 9:56 AM Pavel Stehule wrote: > Hi > > one visitor of p2d2 (Prague PostgreSQL Developer Day) asked if it is > possible to show the current role in psql's prompt. I think it is not > possible, but fortunately (with some limits) almost all necessary work is > done, and the pat

Re: proposal: psql: psql variable BACKEND_PID

> > with doc and unsetting variable > > Regards > > Pavel > > Patch applies. Manually testing confirms that it works, at least for the connected state. I don't actually know how get psql to invoke DISCONNECT, so I killed the dev server and can confirm [81:14:57:01 EST] corey=# \echo :BACKEND_

Re: proposal: psql: psql variable BACKEND_PID

> > >> >> Clearly, it is hard to write a regression test for an externally volatile >> value. `SELECT sign(:BACKEND_PID)` would technically do the job, if we're >> striving for completeness. >> > > I did simple test - :BACKEND_PID should be equal pg_backend_pid() > > Even better. > >> >> Do we w

Re: proposal: psql: psql variable BACKEND_PID

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: tested, passed Documentation:tested, passed A small but helpful feature. The new status of this patch is

Re: appendBinaryStringInfo stuff

On Fri, Feb 10, 2023 at 7:16 AM Peter Eisentraut < peter.eisentr...@enterprisedb.com> wrote: > On 19.12.22 07:13, Peter Eisentraut wrote: > > Also, the argument type of appendBinaryStringInfo() is char *. There is > > some code that uses this function to assemble some kind of packed binary > > la

Re: Improving inferred query column names

On Sat, Feb 11, 2023 at 3:47 PM Vladimir Churyukin wrote: > For backwards compatibility I guess you can have a GUC flag controlling > that behavior that can be set into backwards compatibility mode if required. > The previous functionality can be declared deprecated and removed (with > the flag)

Re: psql memory leaks

On Mon, Feb 20, 2023 at 9:56 PM Kyotaro Horiguchi wrote: > I noticed that \bind is leaking memory for each option. > > =# SELECT $1, $2, $3 \ bind 1 2 3 \g > > The leaked memory blocks are comming from > psql_scan_slash_option(). The attached small patch resolves that > issue. I looked through t

Re: Error-safe user functions

> > > The idea is simple -- introduce new "error-safe" calling mode of user > functions by passing special node through FunctCallInfo.context, in > which function should write error info and return instead of throwing > it. Also such functions should manually free resources before > returning an e

Re: [patch] \g with multiple result sets and \watch with copy queries

> > This is a bit more complicated than the usual tests, but not > that much. > Any opinions on this? +1 I think that because it is more complicated than usual psql, we may want to comment on the intention of the tests and some of the less-than-common psql elements (\set concatenation, resetting

Re: future of serial and identity columns

> > The feedback was pretty positive, so I dug through all the tests to at > least get to the point where I could see the end of it. The attached > patch 0001 is the actual code and documentation changes. The 0002 patch > is just tests randomly updated or disabled to make the whole suite pass. >

WIP: Analyze whether our docs need more granular refentries.

In reviewing another patch, I noticed that the documentation had an xref to a fairly large page of documentation (create_table.sgml), and I wondered if that link was chosen because the original author genuinely felt the entire page was relevant, or merely because a more granular link did not exist

Re: predefined role(s) for VACUUM and ANALYZE

> > Sounds good. Here's a new patch set with aclitem's typalign fixed. > Patch applies. Passes make check and make check-world. Test coverage seems adequate. Coding is very clear and very much in the style of the existing code. Any quibbles I have with the coding style are ones I have with the o

Re: Getting rid of SQLValueFunction

On Fri, Sep 30, 2022 at 2:04 AM Michael Paquier wrote: > Hi all, > > I have bumped a few days ago on the fact that COERCE_SQL_SYNTAX > (introduced by 40c24bf) and SQLValueFunction are around to do the > exact same thing, as known as enforcing single-function calls with > dedicated SQL keywords.

Re: ts_locale.c: why no t_isalnum() test?

On Wed, Oct 5, 2022 at 3:53 PM Tom Lane wrote: > I happened to wonder why various places are testing things like > > #define ISWORDCHR(c)(t_isalpha(c) || t_isdigit(c)) > > rather than using an isalnum-equivalent test. The direct answer > is that ts_locale.c/.h provides no such test function,

Re: refactor ownercheck and aclcheck functions

On Fri, Oct 14, 2022 at 3:39 AM Peter Eisentraut < peter.eisentr...@enterprisedb.com> wrote: > These patches take the dozens of mostly-duplicate pg_foo_ownercheck() > and pg_foo_aclcheck() functions and replace (most of) them by common > functions that are driven by the ObjectProperty table. All

Re: XMAX_LOCK_ONLY and XMAX_COMMITTED (fk/multixact code)

On Tue, Sep 20, 2022 at 2:32 PM Nathan Bossart wrote: > Here is a rebased patch for cfbot. > > > Applies, passes make check world. Patch is straightforward, but the previous code is less so. It purported to set XMAX_COMMITTED _or_ XMAX_INVALID, but never seemed to un-set XMAX_COMMITTED, was that

Re: pg_dump: Refactor code that constructs ALTER ... OWNER TO commands

On Mon, Oct 24, 2022 at 5:54 AM Peter Eisentraut < peter.eisentr...@enterprisedb.com> wrote: > Avoid having to list all the possible object types twice. Instead, only > _getObjectDescription() needs to know about specific object types. It > communicates back to _printTocEntry() whether an owner

Re: psql: Add command to use extended query protocol

> > > SELECT $1, $2 \gp 'foo' 'bar' > > I think this is a great idea, but I foresee people wanting to send that output to a file or a pipe like \g allows. If we assume everything after the \gp is a param, don't we paint ourselves into a corner?

Add SHELL_EXIT_CODE to psql

Over in https://www.postgresql.org/message-id/eaf326ad693e74eba068f33a7f518...@oss.nttdata.com Justin Pryzby suggested that psql might need the ability to capture the shell exit code. This is a POC patch that does that, but doesn't touch on the ON_ERROR_STOP stuff. I've added some very rudimentar

Re: Make ON_ERROR_STOP stop on shell script failure

> > I think it'd be a lot better to expose the script status to psql. > (without having to write "foo; echo status=$?"). > I agree, and I hacked up a proof of concept, but started another thread at https://www.postgresql.org/message-id/CADkLM=cWao2x2f+UDw15W1JkVFr_bsxfstw=ngea7r9m4j-...@mail.gmail

Re: Add SHELL_EXIT_CODE to psql

:SHELL_EXIT_CODE 127 -- good \! \! true \echo :SHELL_EXIT_CODE 0 -- play with exit codes \! exit 4 \echo :SHELL_EXIT_CODE 4 \set var `exit 3` \echo :SHELL_EXIT_CODE 3 On Fri, Nov 4, 2022 at 5:08 AM Corey Huinker wrote: > > Over in > https://www.postgresql.org/m

Re: Emit namespace in post-copy output

On Tue, Jun 22, 2021 at 6:08 PM Mike wrote: > When running a VACUUM or CLUSTER command, the namespace name is not part > of the emitted message. > > Using `vacuumdb` CLI tool recently with multiple jobs, I found that > reading the output messages harder to match the relations with their > namespa

Re: Grammar railroad diagram

> > > Another way that I tested and it's working is to use > https://www.bottlecaps.de/convert/ paste the postgresql grammar there > and press "convert" and after press "view diagram". > I tried this out and I'm pleased to see that one of the outputs is xhtml + SVG, because SVGs have hover-over to

Re: Query generates infinite loop

On Wed, May 4, 2022 at 3:01 PM Jeff Janes wrote: > On Wed, Apr 20, 2022 at 5:43 PM Tom Lane wrote: > >> I wrote: >> > it's true that infinities as generate_series endpoints are going >> > to work pretty oddly, so I agree with the idea of forbidding 'em. >> >> > Numeric has infinity as of late, s

Re: Query generates infinite loop

On Mon, May 9, 2022 at 12:02 AM Tom Lane wrote: > Corey Huinker writes: > > On Wed, May 4, 2022 at 3:01 PM Jeff Janes wrote: > >> On Wed, Apr 20, 2022 at 5:43 PM Tom Lane wrote: > >>> Oh --- looks like numeric generate_series() already throws error for > >

Re: Query generates infinite loop

> > Less sure about that. ISTM the reason that the previous proposal failed > was that it introduced too much ambiguity about how to resolve > unknown-type arguments. Wouldn't the same problems arise here? > If I recall, the problem was that the lack of a date-specific generate_series function w

Re: simplifying foreign key/RI checks

> > Rebased patches attached. I'm reviewing the changes since v6, which was my last review. Making ExecLockTableTuple() it's own function makes sense. Snapshots are now accounted for. The changes that account for n-level partitioning makes sense as well. Passes make check-world. Not user facing

Re: SQL:2011 application time

So I've been eagerly watching this thread and hoping to have time to devote to it. I've also been looking at the thread at https://www.postgresql.org/message-id/calay4q8pp699qv-pjzc4tos-e2nzrjkrvax-xqg1aqj2q+w...@mail.gmail.com that covers system versioning, and per our conversation far too long ag

Re: WIP: System Versioned Temporal Table

On Sun, Sep 12, 2021 at 12:02 PM Simon Riggs wrote: > On Fri, 10 Sept 2021 at 19:30, Jaime Casanova > wrote: > > > > On Tue, Aug 10, 2021 at 01:20:14PM +0100, Simon Riggs wrote: > > > On Wed, 14 Jul 2021 at 12:48, vignesh C wrote: > > > > > > > The patch does not apply on Head anymore, could yo

Re: WIP: System Versioned Temporal Table

> > > > 1. Much of what I have read about temporal tables seemed to imply or > almost assume that system temporal tables would be implemented as two > actual separate tables. Indeed, SQLServer appears to do it that way [1] > with syntax like > > WITH (SYSTEM_VERSIONING = ON (HISTORY_TABLE = dbo.Web

Re: SQL:2011 application time

In IBM DB2 you can only have one because application-time periods must > be named "business_time" (not joking). > I saw that as well, and it made me think that someone at IBM is a fan of Flight Of The Conchords. > Personally I feel like it's a weird limitation and I wouldn't mind > supporting mo

Undocumented AT TIME ZONE INTERVAL syntax

In reviewing Paul's application period patch, I noticed some very curious syntax in the test cases. I learned that Paul is equally confused by it, and has asked about it in his PgCon 2020 presentation > SELECT '2018-03-04' AT TIME ZONE INTERVAL '2' HOUR TO MINUTE; timezone --

Re: Undocumented AT TIME ZONE INTERVAL syntax

On Sun, Sep 19, 2021 at 10:56 AM Tom Lane wrote: > Corey Huinker writes: > >> SELECT '2018-03-04' AT TIME ZONE INTERVAL '2' HOUR TO MINUTE; > > > ... But none of this is in our own documentation. > > That's not entirely true. [1] says >

Re: Undocumented AT TIME ZONE INTERVAL syntax

> > >> Yeah, I really didn't expect to change the behavior, but wanted to make > sure that the existing behavior was understood. I'll whip up a patch. > Attached is an attempt at an explanation of the edge cases I was encountering, as well as some examples. If nothing else, the examples will draw

Re: WIP: System Versioned Temporal Table

> > Thanks for giving this a lot of thought. When you asked the question > the first time you hadn't discussed how that might work, but now we > have something to discuss. > My ultimate goal is to unify this effort with the application period effort. Step 1 in that was to understand what each was

Re: WIP: System Versioned Temporal Table

On Sun, Sep 19, 2021 at 3:12 PM Hannu Krosing wrote: > A side table has the nice additional benefit that we can very easily > version the *table structure* so when we ALTER TABLE and the table > structure changes we just make a new side table with now-currents > structure. > It's true that would

Re: Fwd: Emit namespace in post-copy output

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: not tested Documentation:not tested Passed make check-world. Running make installcheck-world had 2 errors

Nitpick/question: Use of aliases for global variables in functions

I'm using an ongoing patch review to educate myself on parts of the codebase. In src/backend/access/transam/xact.c, I'm noticing a code style inconsistency. In some cases, a function will declare a variable of some struct pointer type, assign it to a globally declared struct, and then use it like

Re: Commitfest manager for July 2024

I'll give it a shot. On Mon, Jul 1, 2024 at 4:16 PM Kirill Reshke wrote: > > Postgres 17 > 18 > > >

Importing Extended Statistics

I'm creating this new thread separate from the existing Statistics Export/Import thread to keep the original thread focused on that patch. Assuming that the function signature for pg_set_attribute_stats() remains the same (regclass, attname, inherited, version, ...stats...), how would we design th

Re: documentation structure

> > > This sounds to me like it would be a painful exercise with not a > > lot of benefit in the end. > > Maybe we could _verify_ the contents of func.sgml against pg_proc. > All of the functions redefined in catalog/system_functions.sql complicate using pg_proc.dat as a doc generator or source of

Re: documentation structure

> > And it's very inconsistent. For example, some functions use > tags for optional parameters, others use square brackets, and some use > VARIADIC to indicate variadic parameters, others use > ellipses (sometimes in tags or brackets). Having just written a couple of those functions, I wasn't

Re: improve performance of pg_dump --binary-upgrade

> > One downside of this approach is the memory usage. This was more-or-less > > Bar-napkin math tells me in a worst-case architecture and braindead byte alignment, we'd burn 64 bytes per struct, so the 100K tables cited would be about 6.25MB of memory. The obvious low-memory alternative would be

Re: documentation structure

> > I havent dealt with variadic yet, since the two styles are visually > different, not just markup (... renders as [...]). > > The two styles for variadic are the what I call caller-style: > >concat ( val1 "any" [, val2 "any" [, ...] ] ) >format(formatstr text [, formatarg "any" [, ...] ]

Re: documentation structure

> > Yeah, we can't expect everyone wanting to call a built-in function to > know how they would define an equivalent one themselves. In that case I > propos marking it up like this: > > format ( > formatstr text > , formatarg "any" > , ... ) > text > Looks good, but I guess I

Re: documentation structure

> > I've splitted it to7 patches. > each patch split one into separate new files. > Seems like a good start. Looking at the diffs of these, I wonder if we would be better off with a func/ directory, each function gets its own file in that dir, and either these files above include the individual f

Re: Virtual generated columns

On Mon, Apr 29, 2024 at 4:24 AM Peter Eisentraut wrote: > Here is a patch set to implement virtual generated columns. > I'm very excited about this! > The main feature patch (0005 here) generally works but has a number of > open corner cases that need to be thought about and/or fixed, many of

Re: Statistics Import and Export

> > Can you explain what you did with the > SECTION_NONE/SECTION_DATA/SECTION_POST_DATA over v19-v21 and why? > Initially, I got things to work by having statistics import behave like COMMENTs, which meant that they were run immediately after the table/matview/index/constraint that created the pg_

Re: Adding SHOW CREATE TABLE

> > 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: Should heapam_estimate_rel_size consider fillfactor?

> > So maybe we should make table_block_relation_estimate_size smarter to > also consider the fillfactor in the "no statistics" branch, per the > attached patch. > I like this a lot. The reasoning is obvious, the fix is simple,it doesn't upset any make-check-world tests, and in order to get a perf

Document efficient self-joins / UPDATE LIMIT techniques.

This patch adds a few examples to demonstrate the following: * The existence of the ctid column on every table * The utility of ctds in self joins * A practical usage of SKIP LOCKED The reasoning for this is a bit long, but if you're interested, keep reading. In the past, there has been a desire

Re: Statistics Import and Export

> > I have attached version 28j as one giant patch covering what was > previously 0001-0003. It's a bit rough (tests in particular need some > work), but it implelements the logic to replace only those values > specified rather than the whole tuple. > I like what you did restoring the parameter en

Re: Statistics Import and Export

> > > git am shows some whitespace error. > Jeff indicated that this was more of a stylistic/clarity reworking. I'll be handling it again for now. > > > +extern Datum pg_set_relation_stats(PG_FUNCTION_ARGS); > +extern Datum pg_set_attribute_stats(PG_FUNCTION_ARGS); > is unnecessary? > They're

July Commitfest: Entries Needing Review

There are currently 124 commitfest entries needing a reviewer. Of those, 38 have activity this month, and the other 86 are a bit more stale, some going back to last year. We're already past the halfway point of this commitfest, so we need to get reviewers on these. If you know your patch isn't go

Re: documentation structure

> > > looking back. > The patch is big. no convenient way to review/validate it. > Perhaps we can break up the patches as follows: 1. create the filelist.sgml entries, and create new files as you detailed, empty with func.sgml still managing the sections, but each section now has it's correspondi

Re: Statistics Import and Export

> * Doc build error and malformatting. > Looking into it. > * I'm not certain that we want all changes to relation stats to be non- > transactional. Are there transactional use cases? Should it be an > option? Should it be transactional for pg_set_relation_stats() but non- > transactional for pg

Re: Statistics Import and Export

> > * pg_set_relation_stats(): the warning: "cannot export statistics > prior to version 9.2" doesn't make sense because the function is for > importing. Reword. > +1 > * I really think there should be a transactional option, just another > boolean, and if it has a default it should be true.

Re: Statistics Import and Export

Giving the parameter lists more thought, the desire for a return code more granular than true/false/null, and the likelihood that each function will inevitably get more parameters both stats and non-stats, I'm proposing the following: Two functions: pg_set_relation_stats( out schemaname name,

Re: Statistics Import and Export

> > > and pg_set_attribute_stats. > pg_set_relation_stats(out schemaname name, out relname name,, out > row_written boolean, out params_entered int, out params_accepted int, > kwargs any[]) > > Oops, didn't hit undo fast enough. Disregard this last bit.

Re: Statistics Import and Export

> > > > WARNING: invalid input syntax for type integer: "four" > > row_written | stats_applied | > > stats_rejected| params_rejected > > -+--+ > > --+- > > t

Re: optimizing pg_upgrade's once-in-each-database steps

On Tue, Aug 6, 2024 at 3:20 PM Nathan Bossart wrote: > On Sun, Aug 04, 2024 at 07:19:57PM +0100, Ilya Gladyshev wrote: > > -- End of review -- > > Thanks for the review. I've attempted to address all your feedback in v8 > of the patch set. I think the names could still use some work, but I > wa

Re: optimizing pg_upgrade's once-in-each-database steps

> > I'll admit I hadn't really considered pipelining, but I'm tempted to say > that it's probably not worth the complexity. Not only do most of the tasks > have only one step, but even tasks like the data types check are unlikely > to require more than a few queries for upgrades from supported ver

Re: Statistics Import and Export

> > > function attribute_statsitics_update() is significantly shorter. (Thank > you for a good set of tests, by the way, which sped up the refactoring > process.) > yw > * Remind me why the new stats completely replace the new row, rather > than updating only the statistic kinds that are speci

Re: More efficient RI checks - take 2

On Wed, Apr 8, 2020 at 1:06 PM Pavel Stehule wrote: > > > st 8. 4. 2020 v 18:36 odesílatel Antonin Houska napsal: > >> After having reviewed [1] more than a year ago (the problem I found was >> that >> the transient table is not available for deferred constraints), I've >> tried to >> implement

Re: Add A Glossary

> > > Term 'relation': A sequence is internally a table with one row - right? > Shall we extend the list of concrete relations by 'sequence'? Or is this > not necessary because 'table' is already there? > I wrote one for sequence, it was a bit math-y for Alvaro's taste, so we're going to try again

Re: Poll: are people okay with function/operator table redesign?

> > Thinking out loud, it'd also be great if we could add in some anchors as > well, so perhaps in the future on the pgweb side we could add in some > discoverable links that other documentation has -- which in turn people > could click / link to others directly to the function name. > +1

Re: Poll: are people okay with function/operator table redesign?

> > Yeah, back at the beginning of this exercise, Alvaro wondered aloud > if we should go to something other than tables altogether. I dunno > what that'd look like though. > It would probably look like our acronyms and glossary pages. Maybe the return example and return values get replaced with

Re: More efficient RI checks - take 2

> > I can imagine removal of the SPI from the current implementation (and > constructing the plans "manually"), but note that the queries I use in my > patch are no longer that trivial. So the SPI makes sense to me because it > ensures regular query planning. > As an intermediate step, in the case

Re: More efficient RI checks - take 2

On Wed, Apr 22, 2020 at 2:36 PM Andres Freund wrote: > Hi, > > On 2020-04-22 13:46:22 -0400, Robert Haas wrote: > > On Wed, Apr 22, 2020 at 1:18 PM Alvaro Herrera > wrote: > > > Well, I was actually thinking in building ready-made execution trees, > > > bypassing the planner altogether. But app

Re: Proposing WITH ITERATIVE

On Wed, Apr 29, 2020 at 10:34 AM Jonah H. Harris wrote: > On Wed, Apr 29, 2020 at 7:22 AM Peter Eisentraut < > peter.eisentr...@2ndquadrant.com> wrote: > >> Yeah the RECURSIVE vs ITERATIVE is a bit of a red herring here. As you >> say, the RECURSIVE keyword doesn't specify the processing but mar

Re: Add A Glossary

On Wed, Apr 29, 2020 at 3:15 PM Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > Why are all the glossary terms capitalized? Seems kind of strange. > > They weren't intended to be, and they don't appear to be in the page I'm looking at. Are you referring to the anchor like in https:/

Re: Proposing WITH ITERATIVE

> > > > Perhaps something like this would be more readable > > > > WITH t AS ( > >UPDATE ( SELECT 1 AS ctr, 'x' as val ) > >SET ctr = ctr + 1, val = val || 'x' > >WHILE ctr <= 100 > >RETURNING ctr, val > > ) > > > > The notion of an UPDATE on an ephemeral subquery isn't that special

Re: PG 13 release notes, first draft

> > > > > > Please do list Jürgen, Corey and Roger as authors of the glossary. > > (Actually I should be listed as well, as the time I spent on it was > considerable.) > +1, the time spent was quite considerable

Re: Referential Integrity Checks with Statement-level Triggers

Attached is a patch that refactors DELETE triggers to fire at the statement level. I chose delete triggers partly out of simplicity, and partly because there some before/after row linkage in the ON UPDATE CASCADE cases where statement level triggers might not be feasible as we have currently imple

Re: \describe*

later. > > If we implement \d as DESCRIBE for server versions as of when DESCRIBE > is actually implemented, we've got wins all around. > > Best, > David. > -- > David Fetter http://fetter.org/ > Phone: +1 415 235 3778 > > Remember to vote! > Conside

Re: Alternative to \copy in psql modelled after \g

> Otherwise "\g -" looks good as a portable solution. +1

Re: Referential Integrity Checks with Statement-level Triggers

> > > While the idea to use the transition table is good, this approach probably > requires the trigger engine (trigger.c) to be adjusted, and that in a > non-trivial way. > It probably does. Several people with advanced knowledge of trigger.c expressed a desire to rebuild trigger.c from the groun

Re: some ri_triggers.c cleanup

On Fri, Feb 22, 2019 at 11:05 AM Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > ri_triggers.c is endlessly long and repetitive. I want to clean it up a > bit (more). > Having just been down this road, I agree that a lot of cleanup is needed and possible. > I looked into all thes

Re: some ri_triggers.c cleanup

On Fri, Feb 22, 2019 at 1:12 PM Corey Huinker wrote: > On Fri, Feb 22, 2019 at 11:05 AM Peter Eisentraut < > peter.eisentr...@2ndquadrant.com> wrote: > >> ri_triggers.c is endlessly long and repetitive. I want to clean it up a >> bit (more). >> > > Having

<    1   2   3   4   5   >