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
> >
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
>
>
>>
>> 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
>
> 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
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
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,
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
>
>
> 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
>
>
> 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
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
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
>
> 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:
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
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 exi
>
> I belive, we need proper includes.
>
Given that wait_error.c already seems to have the right includes worked out
for WEXITSTATUS/WIFSTOPPED/etc, I decided to just add a function there.
I named it wait_result_to_exit_code(), but I welcome suggestions of a
better name.
From
>
>
>
> The patch does not apply on top of HEAD as in [1], please post a rebased
> patch:
>
>
Conflict was due to the doc patch applying id tags to psql variable names.
I've rebased and added my own id tags to the two new variables.
From 9e2827a6f955e7cebf87ca538fab113a359951b4 Mon Sep 17 00:00:00
On Tue, Jan 10, 2023 at 3:54 AM Maxim Orlov wrote:
>
>
> On Mon, 9 Jan 2023 at 21:36, Corey Huinker
> wrote:
>
>>
>> I chose a name that would avoid collisions with anything a user might
>> potentially throw into their environment, so if the var "OS"
On Mon, Jan 9, 2023 at 10:01 AM Maxim Orlov wrote:
> Hi!
>
> In overall, I think we move in the right direction. But we could make code
> better, should we?
>
> + /* Capture exit code for SHELL_EXIT_CODE */
> + close_exit_code = pclose(fd);
> + if
On Thu, Jan 5, 2023 at 8:50 AM Drouvot, Bertrand <
bertranddrouvot...@gmail.com> wrote:
> Hi hackers,
>
> Please find attached a patch proposal to $SUBJECT.
>
> This is the same kind of work that has been done in 83a1a1b566 and
> 8018ffbf58 but this time for the
> pg_stat_get_xact*() functions
On Tue, Jan 3, 2023 at 5:36 AM vignesh C wrote:
> On Wed, 21 Dec 2022 at 11:04, Corey Huinker
> wrote:
> >
> > I've rebased and updated the patch to include documentation.
> >
> > Regression tests have been moved to a separate patchfile because error
> messages
On Mon, Jan 2, 2023 at 10:57 AM Tom Lane wrote:
> Corey Huinker writes:
> > The proposed changes are as follows:
> > CAST(expr AS typename)
> > continues to behave as before.
> > CAST(expr AS typename ERROR ON ERROR)
> > has the identical behavior as the
On Sat, Dec 31, 2022 at 5:28 PM Isaac Morland
wrote:
> On Sat, 31 Dec 2022 at 16:47, Corey Huinker
> wrote:
>
>>
>>> I wonder if there is value in setting up a psql on/off var
>>> SHELL_ERROR_OUTPUT construct that when set to "off/false"
>>> s
On Fri, Dec 30, 2022 at 2:17 PM Corey Huinker
wrote:
> On Wed, Dec 28, 2022 at 5:59 AM Maxim Orlov wrote:
>
>> Hi!
>>
>> The patch is implementing what is declared to do. Shell return code is
>> now accessible is psql var.
>> Overall code is in a good conditi
On Wed, Dec 28, 2022 at 5:59 AM Maxim Orlov wrote:
> Hi!
>
> The patch is implementing what is declared to do. Shell return code is now
> accessible is psql var.
> Overall code is in a good condition. Applies with no errors on master.
> Unfortunately, regression tests are failing on the macOS
, 2022 at 12:35 AM Corey Huinker
wrote:
> 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:
>>
>> -- SHEL
>
> How about this new one with variable arguments?
I like this a lot, but I also see merit in Alvaro's PERCENT_OPT variadic,
which at least avoids the two lists getting out of sync.
Initially, I was going to ask that we have shell-quote-safe equivalents of
whatever fixed parameters we baked
Attached is my work in progress to implement the changes to the CAST()
function as proposed by Vik Fearing.
This work builds upon the Error-safe User Functions work currently ongoing.
The proposed changes are as follows:
CAST(expr AS typename)
continues to behave as before.
CAST(expr AS
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
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
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
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'
> >
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
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
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
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
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
> -
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,
> >
>
> 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
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 other da
On Fri, Dec 2, 2022 at 9:34 AM Andrew Dunstan wrote:
>
> On 2022-12-02 Fr 09:12, Tom Lane wrote:
> > Robert Haas writes:
> >> I think the design is evolving in your head as you think about this
> >> more, which is totally understandable and actually very good. However,
> >> this is also why I
On Fri, Dec 2, 2022 at 9:12 AM Tom Lane wrote:
> Robert Haas writes:
> > I think the design is evolving in your head as you think about this
> > more, which is totally understandable and actually very good. However,
> > this is also why I think that you should produce the patch you
> > actually
On Tue, Nov 15, 2022 at 8:29 AM Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
> On 09.11.22 00:12, Corey Huinker wrote:
> > As for the docs, they're very clear and probably sufficient as-is, but I
> > wonder if we should we explicitly state that th
On Tue, Nov 15, 2022 at 11:36 AM Andrew Dunstan wrote:
>
> On 2022-10-07 Fr 13:37, Tom Lane wrote:
>
>
> [ lots of detailed review ]
>
> > Basically, this patch set should be a lot smaller and not have ambitions
> > beyond "get the API right" and "make one or two datatypes support COPY
> >
>
> WITH data_src AS (SELECT * FROM source_tbl),
> insert_a AS (INSERT INTO a SELECT * FROM data_src WHERE d < 5),
> insert_b AS (INSERT INTO b SELECT * FROM data_src WHERE d >= 5)
> INSERT INTO c SELECT * FROM data_src WHERE d < 5
>
I suppose you could just do a dummy SELECT at the bottom to
On Mon, Nov 14, 2022 at 7:06 PM Alexandre hadjinlian guerra <
alexhgue...@gmail.com> wrote:
> Hello
> Are there any plans to incorporate a formal syntax multitable/conditional
> insert , similar to the syntax below? snowflake does have the same feature
>
>
>
>
> +if you are reading this prepatorily, please redesign your
> query to use temporary tables or arrays
>
I agree with the documentation of this parameter.
I agree with dissuading anyone from attempting to change it
The wording is bordering on snark (however well deserved) and I think the
>
> After considering this again, I decided to brute-force this and get rid
> of all the trivial wrapper functions and also several of the special
> cases. That way, there is less confusion at the call sites about why
> this or that style is used in a particular case. Also, it now makes
> sure
>
>
> Btw., this also allows doing things like
>
> SELECT $1, $2
> \bind '1' '2' \g
> \bind '3' '4' \g
>
That's one of the things I was hoping for. Very cool.
>
> This isn't a prepared statement being reused, but it relies on the fact
> that psql \g with an empty query buffer resends the
On Mon, Nov 7, 2022 at 4:12 PM Tom Lane wrote:
> Corey Huinker writes:
> > I thought about basically reserving the \$[0-9]+ space as bind variables,
> > but it is possible, though unlikely, that users have been naming their
> > variables like that.
>
> Don't we
>
>
>
> what about introduction new syntax for psql variables that should be
> passed as bind variables.
>
I thought about basically reserving the \$[0-9]+ space as bind variables,
but it is possible, though unlikely, that users have been naming their
variables like that.
It's unclear from your
On Wed, Nov 2, 2022 at 5:30 PM Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
> On 01.11.22 13:59, Corey Huinker wrote:
> > On Mon, Oct 24, 2022 at 5:54 AM Peter Eisentraut
> > > <mailto:peter.eisentr...@enterprisedb.com>> wrote:
> >
> &
On Fri, Nov 4, 2022 at 11:45 AM Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
> On 02.11.22 01:18, Corey Huinker wrote:
> >
> > SELECT $1, $2 \gp 'foo' 'bar'
> >
> >
> > I think this is a great idea, but I foresee people wanting to s
: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
>
> 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
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
>
>
> 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?
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
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
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
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
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.
>
> 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
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
>
> 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.
>
>
> 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,
>
>
> 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
>
> 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
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
>
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,
On Tue, Mar 15, 2022 at 5:24 PM Greg Stark wrote:
> This looks like an awesome addition.
>
> I have one technical questions...
>
> Is it possible to actually transform the row_number case into a LIMIT
> clause or make the planner support for this case equivalent to it (in
> which case we can
>
>
> The spec does not allow schema changes at all on a a system versioned
> table, except to change the system versioning itself.
>
>
That would greatly simplify things!
>
>
> > 2. Putting data in a side table. This makes DROP SYSTEM VERSIONING
> > fairly trivial, but it complicates many DDL commands (please make a
> > list?) and requires the optimizer to know about this and cater to it,
> > possibly complicating plans. Neither issue is insurmountable, but it
> >
>
> Hmm ... not really, because for these particular functions, the
> point is exactly that we *don't* translate them to some function
> call on the remote end. We evaluate them locally and push the
> resulting constant to the far side, thus avoiding issues like
> clock skew.
>
Ah, my pattern
> The implementation of converting now() to CURRENT_TIMESTAMP
> seems like an underdocumented kluge, too.
>
I'm very late to the party, but it seems to me that this effort is
describing a small subset of what "routine mapping" seems to be for:
defining function calls that can be pushed down to
>
> I'd be
> curious to know where we found the bits for that -- the tuple header
> isn't exactly replete with extra bit space.
>
+1 - and can we somehow shoehorn in a version # into the new format so we
never have to look for spare bits again.
>
>
> But
> the standard says that dropping system versioning should automatically
> drop all historical records (2 under Part 2: Foundation, 11.30 system versioning clause>). That actually makes sense though: when you
> do DML we automatically update the start/end columns, but we don't
> save
On Thu, Jan 6, 2022 at 12:18 PM Andrew Dunstan wrote:
>
> On 1/4/22 22:17, Corey Huinker wrote:
> >
> > currently a failed cast throws an error. It would be useful to have a
> > way to get a default value instead.
> >
> >
> > I've recently en
On Wed, Jan 5, 2022 at 11:07 AM Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
> On 21.11.21 02:51, Paul A Jungwirth wrote:
> > Here are updated patches. They are rebased and clean up some of my
> > TODOs.
>
> This patch set looks very interesting. It's also very big, so it's
>
>
> currently a failed cast throws an error. It would be useful to have a
> way to get a default value instead.
>
I've recently encountered situations where this would have been helpful.
Recently I came across some client code:
CREATE OR REPLACE FUNCTION is_valid_json(str text) RETURNS boolean
>
>
> First, there is only one FK in permission pointing to role, and we write a
> query leaving out the key columns.
> Then, another different FK in permission pointing to role is later added,
> and our old query is suddenly in trouble.
>
>
We already have that problem with cases where two tables
>
>
>
> Perhaps this would be more SQL idiomatic:
>
> FROM permission p
>LEFT JOIN ON KEY role IN p AS r
>LEFT JOIN team_role AS tr ON KEY role TO r
>LEFT JOIN ON KEY team IN tr AS t
>LEFT JOIN user_role AS ur ON KEY role TO r
>LEFT JOIN ON KEY user IN ur AS u
>
>
My second
>
>
>
> Good catch, thanks. Patch updated.
>
>
>
Applies clean. Passes check-world.
>
> Out of curiosity, could you please tell me the concrete situations
> where you wanted to delete one of two identical records?
>
In my case, there is a table with known duplicates, and we would like to
delete all but the one with the lowest ctid, and then add a unique index to
the table which
>
>
>
> I wasn't able to make much inroads into how we might be able to get
> rid of the DETACH-related partition descriptor hacks, the item (3),
> though I made some progress on items (1) and (2).
>
> For (1), the attached 0001 patch adds a new isolation suite
> fk-snapshot.spec to exercise
On Sun, Dec 19, 2021 at 7:00 PM Tom Lane wrote:
> Corey Huinker writes:
> > Which brings up a tangential question, is there value in having something
> > that brings in one or more env vars as psql vars directly. I'm thinking
> > something like:
>
> > \impo
On Sun, Dec 19, 2021 at 5:48 PM Tom Lane wrote:
> Corey Huinker writes:
> > I have a nitpick about the \getenv FOO FOO lines.
> > It's a new function to everyone, and to anyone who hasn't seen the
> > documentation it won't be immediately obvious which one is the ENV va
>
>
> 0001 adds the \getenv command to psql; now with documentation
> and a simple regression test.
>
+1. Wish I had added this years ago when I had a need for it.
>
> 0002 tweaks pg_regress to export the needed values as environment
> variables, and modifies the test scripts to use those
On Sun, Dec 5, 2021 at 11:15 AM Daniel Gustafsson wrote:
> > On 5 Dec 2021, at 16:51, Brar Piening wrote:
>
> > The attached patch adds id's to various elements in protocol.sgml to
> > make them more accesssible via the public html documentation interface.
>
> Off the cuff without having
>
> build support and made the Perl code more portable, so that the cfbot
> doesn't have to be sad.
>
Was this also the reason for doing the output with print statements rather
than using one of the templating libraries? I'm mostly just curious, and
certainly don't want it to get in the way of
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
>
> 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
>
>
>> 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
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
>
> When writing a
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
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
>
>
>
> 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 =
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
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
>
> 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
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
101 - 200 of 308 matches
Mail list logo
