>
> I wonder if the right answer to that is "let's enhance the I/O
> functions for those types". But whether that helps or not, it's
> v18-or-later material for sure.
>
That was Stephen's take as well, and I agreed given that I had to throw the
kitchen-sink of source-side oid mappings (attname, t
>
>
> I concur with the plan of extracting data from pg_stats not
> pg_statistics, and with emitting a single "set statistics"
> call per attribute. (I think at one point I'd suggested a call
> per stakind slot, but that would lead to a bunch of UPDATEs on
> existing pg_attribute tuples and hence
>
> IIRC, "variadic any" requires having at least one variadic parameter.
> But that seems fine --- what would be the point, or even the
> semantics, of calling pg_set_attribute_stats with no data fields?
>
If my pg_dump run emitted a bunch of stats that could never be imported,
I'd want to know.
>
> That's not what I suggested at all. The function parameters would
> be declared anyarray, but the values passed to them would be coerced
> to the correct concrete array types. So as far as the coercion rules
> are concerned this'd be equivalent to the variadic-any approach.
>
+1
>
> > Tha
>
> I think pg_upgrade could check for the existence of extended statistics
> in any database and adjust the analyze recommdnation wording
> accordingly.
>
+1
>
> Ah, yeah, you could change the function to have more parameters,
> given the assumption that all calls will be named-parameter style.
> I still suggest that my proposal is more robust for the case where
> the dump lists parameters that the receiving system doesn't have.
>
So what's the behavio
>
>
> I still think that we could just declare the function strict, if we
> use the variadic-any approach. Passing a null in any position is
> indisputable caller error. However, if you're allergic to silently
> doing nothing in such a case, we could have pg_set_attribute_stats
> check each argum
>
> If we are envisioning that the function might emit multiple warnings
> per call, a useful definition could be to return the number of
> warnings (so zero is good, not-zero is bad). But I'm not sure that's
> really better than a boolean result. pg_dump/pg_restore won't notice
> anyway, but per
Here's a one-liner patch for disabling update of pg_class
relpages/reltuples/relallviible during a binary upgrade.
This was causting pg_upgrade tests to fail in the existing stats import
work.
From 322db8c9e8796ce673f7d7b63bd64e4c9403a144 Mon Sep 17 00:00:00 2001
From: Corey Huinker
Date: M
I have refactored pg_set_relation_stats to be variadic, and I'm working on
pg_set_attribute_sttats, but I'm encountering an issue with the anyarray
values.
Jeff suggested looking at anyarray_send as a way of extracting the type,
and with some extra twiddling we can get and cast the type. However,
>
> side to know the element type anyway. So, I apologize for sending
> us down a useless side path. We may as well stick to the function
> signature as shown in the v15 patch --- although maybe variadic
> any is still worthwhile so that an unrecognized field name doesn't
> need to be a hard erro
>
> Yeah, but that problem exists no matter what. I haven't read enough
> of the patch to find where it's determining that, but I assume there's
> code in there to intuit the statistics storage type depending on the
> table column's data type and the statistics kind.
>
Correct. It borrows a lot f
>
>
> As far as that goes, it shouldn't be that hard to deal with, at least
> not for "soft" errors which hopefully cover most input-function
> failures these days. You should be invoking array_in via
> InputFunctionCallSafe and passing a suitably-set-up ErrorSaveContext.
> (Look at pg_input_error
>
> For a partitioned table this value has to be true. For a normal table when
> setting this value to true, it should at least make sure that the table has
> at least one child. Otherwise it should throw an error. Blindly accepting
> the given value may render the statistics unusable. Prologue of
>
>
>
> I think it'll be a serious, serious error for this not to be
> SECTION_DATA. Maybe POST_DATA is OK, but even that seems like
> an implementation compromise not "the way it ought to be".
>
We'd have to split them on account of when the underlying object is
created. Index statistics would b
the "in" before between is unnecessary and had better be removed,
> but
> I'll defer to the native speaker.
>
The "in" is more common when spoken. Removed.
From a6b57bf3a88c5df614b5dede99af3e99fe8e8089 Mon Sep 17 00:00:00 2001
From: Corey Huinker
Date: Mon, 12
>
> Do you plan to add it to the commitfest? If yes, I'd set it "ready for
> committer".
>
> Commitfest entry reanimated.
>
> Also, it says "statistics are replaced" but it's quite clear if that
> applies only to matching statistics or if all stats are deleted first
> and then the new stuff is inserted. (FWIW remove_pg_statistics clearly
> deletes all pre-existing stats).
>
All are now deleted first, both in the pg_s
On Tue, Feb 13, 2024 at 11:51 AM Joel Jacobson wrote:
> On Tue, Feb 13, 2024, at 10:28, Laurenz Albe wrote:
> > On Mon, 2024-02-12 at 12:24 -0500, Corey Huinker wrote:
> >> > Do you plan to add it to the commitfest? If yes, I'd set it "ready
> for comm
>
> > As for whether it's commonplace, when I was a consultant I had a number
> > of customers that I had who bemoaned how large updates caused big
> > replica lag, basically punishing access to records they did care about
> > in order to properly archive or backfill records they don't care about.
>
>
>
> Having looked through this thread and discussed a bit with Corey
> off-line, the approach that Tom laid out up-thread seems like it would
> make the most sense overall- that is, eliminate the JSON bits and the
> SPI and instead export the stats data by running queries from the new
> version
>
>
> That’s certainly a fair point and my initial reaction (which could
> certainly be wrong) is that it’s unlikely to be an issue- but also, if you
> feel you could make it work with an array and passing all the attribute
> info in with one call, which I suspect would be possible but just a bit
>
>
>
> > BEGIN;
> > LOCK TABLE schema.relation IN SHARE UPDATE EXCLUSIVE MODE;
> > LOCK TABLE pg_catalog.pg_statistic IN ROW UPDATE EXCLUSIVE MODE;
> > SELECT pg_import_rel_stats('schema.relation', ntuples, npages);
> > SELECT pg_import_pg_statistic('schema.relation', 'id', ...);
> > SELECT pg_impor
ils work, mostly
because what I do there heavily depends on how this is received.
Also, I'm still seeking confirmation that I can create a pg_dump TOC entry
with a chain of commands (e.g. BEGIN; ... COMMIT; ) or if I have to fan
them out into multiple entries.
Anyway, here's v7. Eagerly a
>
> Perhaps it's just me ... but it doesn't seem like it's all that many
>
parameters.
>
It's more than I can memorize, so that feels like a lot to me. Clearly it's
not insurmountable.
> > I am a bit concerned about the number of locks on pg_statistic and the
> > relation itself, doing CatalogO
On Sun, Mar 10, 2024 at 11:57 AM Bharath Rupireddy <
bharath.rupireddyforpostg...@gmail.com> wrote:
> On Fri, Mar 8, 2024 at 12:06 PM Corey Huinker
> wrote:
> >
> > Anyway, here's v7. Eagerly awaiting feedback.
>
> Thanks for working on this. It looks useful t
;id'::name, ...),
pg_set_attribute_stats(t.oid, 'last_name'::name, ...),
...
FROM (VALUES('foo.bar'::regclass)) AS t(oid);
The second one has the feature that if any one attribute fails, then the
whole update fails, except, of course, for the in-pla
>
> > In which case we're failing nearly silently, yes, there is a null
> returned,
> > but we have no idea why there is a null returned. If I were using this
> > function manually I'd want to know what I did wrong, what parameter I
> > skipped, etc.
>
> I can see it both ways and don't feel super
>
> No, we should be keeping the lock until the end of the transaction
> (which in this case would be just the one statement, but it would be the
> whole statement and all of the calls in it). See analyze.c:268 or
> so, where we call relation_close(onerel, NoLock); meaning we're closing
> the rela
>
> Note that there's two different things we're talking about here- the
> lock on the relation that we're analyzing and then the lock on the
> pg_statistic (or pg_class) catalog itself. Currently, at least, it
> looks like in the three places in the backend that we open
> StatisticRelationId, we
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 typ
>
> 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 in,
Sun, Dec 4, 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:
>>
>&g
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 due
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 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 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 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
> mess
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 (as
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 (close_
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"
>
>
>
> 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
>
> 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 9e2827a6f955e7cebf87
On Tue, Mar 28, 2023 at 2:53 PM Gregory Stark (as CFM)
wrote:
> On Tue, 3 Jan 2023 at 14:16, Tom Lane wrote:
> >
> > Vik Fearing writes:
> >
> > > I don't think we should add that syntax until I do get it through the
> > > committee, just in case they change something.
> >
> > Agreed. So this
On Tue, Mar 28, 2023 at 3:25 PM Isaac Morland
wrote:
> On Mon, 19 Dec 2022 at 17:57, Corey Huinker
> wrote:
>
>>
>> Attached is my work in progress to implement the changes to the CAST()
>> function as proposed by Vik Fearing.
>>
>> CAST(expr AS typena
On Wed, Mar 29, 2023 at 12:54 AM Yugo NAGATA wrote:
> Hello,
>
>
> Temporary tables are often used to store transient data in
> batch processing and the contents can be accessed multiple
> times. However, frequent use of temporary tables has a problem
> that the system catalog tends to bloat. I k
On Wed, Mar 29, 2023 at 8:51 AM Drouvot, Bertrand <
bertranddrouvot...@gmail.com> wrote:
> Hi,
>
> On 3/29/23 11:44 AM, Drouvot, Bertrand wrote:
>
> >
> > Looking forward to your feedback,
>
> Just realized that more polishing was needed.
>
> Done in V2 attached.
>
> Regards,
>
> --
> Bertrand Dro
Is there a barrier to us using non-core perl modules, in this case
Text::Template?
I think it would be a tremendous improvement in readability and
maintainability over our current series of print statements, some
multiline, some not.
The module itself works like this https://www.perlmonks.org/?no
>
> I think many of those could just be replaced by multi-line strings and/or
> here
> documents to get most of the win.
>
I agree that a pretty good chunk of it can be done with here-docs, but
template files do have attractive features (separation of concerns, syntax
highlighting, etc) that made
>
> I don't think that's remotely a starter. Asking people to install an old
> and possibly buggy version of a perl module is not something we should do.
>
> I think the barrier for this is pretty high. I try to keep module
> requirements for the buildfarm client pretty minimal, and this could affe
>
> Yeah, it's somewhat hard to believe that the cost/benefit ratio would be
> attractive. But maybe you could mock up some examples of what the input
> could look like, and get people on board (or not) before writing any
> code.
>
>
tl;dr - I tried a few things, nothing that persuades myself let
On Fri, Mar 24, 2023 at 5:21 PM Corey Huinker
wrote:
>
>
> On Tue, Mar 21, 2023 at 3:33 PM Corey Huinker
> wrote:
>
>>
>>> As you had it, any nonzero result would prevent backtick substitution.
>>> I'm not really sure how much thought went into the
On Wed, Apr 12, 2023 at 10:40 AM David Gilman
wrote:
> The SQL Language part of the docs has a brief page on unique indexes.
> It doesn't mention the new NULLS NOT DISTINCT functionality on unique
> indexes and this is a good place to mention it, as it already warns
> the user about the old/defau
On Wed, May 3, 2023 at 1:37 AM Thomas Munro wrote:
> On Wed, May 3, 2023 at 5:21 PM Thomas Munro
> wrote:
> > rsync --link-dest
>
> I wonder if rsync will grow a mode that can use copy_file_range() to
> share blocks with a reference file (= previous backup). Something
> like --copy-range-dest.
here is to aid in discovery. A user might miss
the technique for update if it's only documented in delete, and even if
they did see it there, they might not realize that it works for both UPDATE
and DELETE. We could make reference links from one to the other, but that
seems like extra work for
>
>
>
> Maybe I just don't understand, but I'm pretty sure ANALYZE does not
> derive index stats from column stats. It actually builds them from the
> row sample.
>
That is correct, my error.
>
> > * now support extended statistics except for MCV, which is currently
> > serialized as an difficul
On Fri, Dec 15, 2023 at 3:36 AM Andrei Lepikhov
wrote:
> On 13/12/2023 17:26, Corey Huinker wrote:> 4. I don't yet have a
> complete vision for how these tools will be used
> > by pg_upgrade and pg_dump/restore, the places where these will provide
> > the biggest win
On Mon, Dec 25, 2023 at 8:18 PM Tomas Vondra
wrote:
> Hi,
>
> I finally had time to look at the last version of the patch, so here's a
> couple thoughts and questions in somewhat random order. Please take this
> as a bit of a brainstorming and push back if you disagree some of my
> comments.
>
>
>
>
> As mentioned already, we'd also need some sort of
> version identifier, and we'd expect the load_statistics() functions
> to be able to transform the data if the old version used a different
> representation. I agree with the idea that an explicit representation
> of the source table attri
>
> Yeah, this is pretty much what I meant by "functional" interface. But if
> I said maybe the format implemented by the patch is maybe too close to
> how we store the statistics, then this has exactly the same issue. And
> it has other issues too, I think - it breaks down the stats into
> multipl
On Wed, Dec 27, 2023 at 10:10 PM Tom Lane wrote:
> Corey Huinker writes:
> > Export functions was my original plan, for simplicity, maintenance, etc,
> > but it seemed like I'd be adding quite a few functions, so the one view
> > made more sense for an initial version.
>
> But maybe it's enough to just do what you did - if we get an MCELEM
> slot, can it ever contain anything else than array of elements of the
> attribute array type? I'd bet that'd cause all sorts of issues, no?
>
>
Thanks for the explanation of why it wasn't working for me. Knowing that
the case
pg_stats_export is a view that aggregates pg_statistic data by relation
oid and stores all of the column statistical data in a system-indepdent
(i.e.
no oids, collation information removed, all MCV values rendered as text)
jsonb format, along with the relation's relname, reltuples, and relpages
fro
On Wed, Jun 28, 2023 at 2:20 PM Corey Huinker
wrote:
> This patch adds a few examples to demonstrate the following:
>
Bumping so CF app can see thread.
>
>
>
> Thanks. I think this may be used with postgres_fdw to import
> statistics directly from the foreigns server, whenever possible,
> rather than fetching the rows and building it locally. If it's known
> that the stats on foreign and local servers match for a foreign table,
> we will be one step
>
> The PERIOD patch is not finished and includes some deliberately-failing
> tests. I did make some progress here finishing ALTER TABLE ADD PERIOD.
>
If it's ok with you, I need PERIODs for System Versioning, and planned on
developing a highly similar version, albeit closer to the standard. It
sh
e can link to the glossary from
outside if we so choose.
I encourage everyone to read the definitions, and suggest fixes to any
inaccuracies or awkward phrasings. Mostly, though, I'm seeking feedback on
the structure itself, and hoping to get that committed.
On Tue, Feb 11, 2020 at 11:22 P
On Wed, Mar 11, 2020 at 12:50 PM Jürgen Purtz wrote:
> I made changes on top of 0001-add-glossary-page.patch which was supplied
> by C. Huinker. This affects not only terms proposed by me but also his
> original terms. If my changes are not obvious, please let me know and I
> will describe my mot
>
> It will be helpful for diff-ing to restrict the length of lines in the
> SGML files to 71 characters (as usual).
I did it that way for the following reasons
1. It aids grep-ability
2. The committers seem to be moving towards that for SQL strings, mostly
for reason #1
3. I recall that the code
>
>
> * Transaction - yes, all those things could be "visible" or they could be
> "side effects". It may be best to leave the over-simplified definition in
> place, and add a "For more information see < tutorial-transactions>>
>
transaction-iso would be a better linkref in this case
On Fri, Mar 13, 2020 at 12:18 AM Jürgen Purtz wrote:
>
> The statement that names of schema objects are unique isn't *strictly* true,
> just *mostly* true. Take the case of a unique constraints.
>
> Concerning CONSTRAINTS you are right. Constraints seems to be an exception:
>
>- Their name be
On Thu, Mar 19, 2020 at 8:11 PM Alvaro Herrera
wrote:
> I gave this a look. I first reformatted it so I could read it; that's
> 0001. Second I changed all the long items into s, which
>
Thanks! I didn't know about xrefs, that is a big improvement.
> are shorter and don't have to repeat the
>
> Jürgen mentioned off-list that the man page doesn't build. I was going to
>> look into that, but if anyone has more familiarity with that, I'm listening.
>>
>
Looking at this some more, I'm not sure anything needs to be done for man
pages. man1 is for executables, man3 seems to be dblink and SP
>
> It's hard to review work from a professional tech writer. I'm under the
> constant impression that I'm ruining somebody's perfect end product,
> making a fool of myself.
If it makes you feel better, it's a mix of definitions I wrote that Roger
proofed and restructured, ones that Jürgen had w
On Fri, Mar 20, 2020 at 6:32 PM Jürgen Purtz wrote:
> man pages: Sorry, if I confused someone with my poor English. I just
> want to express in my 'offline' mail that we don't have to worry about
> man page generation. The patch doesn't affect files in the /ref
> subdirectory from where man pages
>
> Perhaps this is what you mean by "deterministic", but isn't it
> possible for some collations to treat multiple byte sequences as equal
> values? And those multiple byte sequences wouldn't necessarily occur
> sequentially in C collation, so it wouldn't be possible to work around
> that by havin
>
>
> > > + Records to the file system and creates a special
> >
> > Does the chckpointer actually write WAL ?
>
> Yes.
>
> > An FK doesn't require the values in its table to be unique, right ?
>
> I believe it does require that the values are unique.
>
> > I think there's some confusion. Con
On Sun, Mar 29, 2020 at 5:29 AM Jürgen Purtz wrote:
> On 27.03.20 21:12, Justin Pryzby wrote:
> > On Fri, Mar 20, 2020 at 11:32:25PM +0100, Jürgen Purtz wrote:
> +Archiver
> >>> Can you change that to archiver process ?
> >> I prefer the short term without the addition of 'process' - con
On Tue, Mar 31, 2020 at 2:09 PM Justin Pryzby wrote:
> On Sun, Oct 13, 2019 at 04:52:05PM -0400, Corey Huinker wrote:
> > 1. It's obviously incomplete. There are more terms, a lot more, to add.
>
> How did you come up with the initial list of terms ?
>
1. I asked some n
>
> 2. I found out that "see xyz" and "see also" have bespoke markup in
> Docbook -- and . I changed some glossentries
> to use those, removing some glossdefs and changing a couple of paras to
> glossseealsos. I also removed all "id" properties from glossentries
> that are just , because I think
>
> I propose we define "planner" and make "optimizer" a entry.
>
I have no objection to more entries, or edits to entries, but am concerned
that the process leads to someone having to manually merge several
start-from-scratch patches, with no clear sense of when we'll be done. I
may make sense t
On Thu, Apr 2, 2020 at 8:44 AM Jürgen Purtz wrote:
> +1 and many thanks to Alvaros edits.
>
>
I did some of the grunt work Alvaro alluded to in v6, and the results are
attached and they build, which means there are no invalid links.
Notes:
* no definition wordings were changed
* added a linkend
>
> we have it, we can start thinking of patching the main part of the docs
> to make reference to it by using in key spots. Right now
> the glossary links to itself, but it makes lots of sense to have other
> places point to it.
>
I have some ideas about how to patch the main docs, but will lea
On Sat, Apr 4, 2020 at 2:55 AM Fabien COELHO wrote:
>
> > BTW it's now visible at:
> > https://www.postgresql.org/docs/devel/glossary.html
Nice. I went looking for it yesterday and the docs hadn't rebuilt yet.
> ISTM that occurrences of these words elsewhere in the documentation should
> link
> 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 the
>
> 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 mat
>
>
> > 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
> > b
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
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:
> >
> &
>
>
>
> 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 e
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 w
>
>
> 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 previou
>
> 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 yo
>
>
> +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
v
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
>
> https://oracle-base.com/articles/9i/multi
>
> 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 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
> > NULL_O
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 th
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 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 th
101 - 200 of 444 matches
Mail list logo
