Attached is the latest patch against HEAD - basically fixes a few typos.
Cheers,
Greg
v3-psql-df-pick-function-by-type.patch
Description: Binary data
On Sat, Jan 2, 2021 at 1:56 AM Thomas Munro wrote:
> ...
> It looks like there is a collation dependency here that causes the
> test to fail on some systems:
>
Thanks for pointing that out. I tweaked the function definitions to
hopefully sidestep the ordering issue - attached is v4.
Cheers,
Gre
Thank you for looking this over.
> This isn't working for arrays:
> ...
> postgres=# \df aa aa int[]
>
Arrays should work as expected, I think you have one too many "aa" in there?
> I think it should use the same syntax as \sf and \ef, which require
> parenthesis
> and commas, not spaces.
>
H
Thanks for the feedback, attached is version two of the patch. Major
changes:
* Use booleans not generic "int x"
* Build a quick list of abbreviations at the top of the function
* Add array mapping for all types
* Removed the tab-complete bit, it was too fragile and unhelpful
Cheers,
Greg
diff --
Thanks for looking this over!
> some Abbreviations of common types are not added to the
> type_abbreviations[] Such as:
>
> Int8=> bigint
>
I wasn't aiming to provide a canonical list, as I personally have never
seen anyone use int8 instead of bigint when (for example) creating a
On Sun, Nov 1, 2020 at 12:05 PM David Christensen wrote:
>
> I can’t speak for the specific patch, but tab completion of proc args for
> \df, \ef and friends has long been a desired feature of mine, particularly
> when you are dealing with functions with huge numbers of arguments and the
> same n
Thanks so much: the Bucardo PR has been merged in.
Thanks for the feedback: new version v5 (attached) has int8, plus the
suggested code formatting.
Cheers,
Greg
v5-psql-df-pick-function-by-type.patch
Description: Binary data
Ha ha ha, my bad, I am not sure why I left those out. Here is a new patch
with int2, int4, and int8. Thanks for the email.
Cheers,
Greg
v6-psql-df-pick-function-by-type.patch
Description: Binary data
I like the wildcard aspect, but I have a few issues with the patch:
* It doesn't respect some common abbreviations that work elsewhere (e.g.
CREATE FUNCTION). So while "int4" works, "int" does not. Nor does "float",
which thus requires the mandatory-double-quoted "double precision"
* Adding comma
On Wed, Feb 7, 2024 at 9:05 AM Peter Eisentraut
wrote:
> I came across the Perl autodie pragma
> (https://perldoc.perl.org/autodie). This seems pretty useful; is this
> something we can use? Any drawbacks? Any minimum Perl version?
Big +1
No drawbacks. I've been using it heavily for many, m
>
> 2. Don't wait, migrate them all now. This would mean requiring
> Perl 5.10.1 or later to run the TAP tests, even in back branches.
>
#2 please. For context, meson did not even exist in 2009.
Cheers,
Greg
Going to agree with Robert Treat here about an extension being a great
solution. I resisted posting earlier as I wanted to see how this all pans
out, but I wrote a quick little POC extension some months ago that does
the disabling and works well (and cannot be easily worked around).
On Mon, Mar 18
On Tue, Mar 19, 2024 at 12:05 PM Tom Lane wrote:
> If you aren't willing to build a solution that blocks off mods
> using COPY TO FILE/PROGRAM and other readily-available-to-superusers
> tools (plpythonu for instance), I think you shouldn't bother asking
> for a feature at all. Just trust your s
Rebased version attached (v2), with another sentence in the sgml to explain
the optional use of -d
Cheers,
Greg
pgbench.dash.d.or.not.dash.d.v2.patch
Description: Binary data
>
> As a bonus, if that GUC is set, we could even check at server startup that
> all the configuration files are not writable by the postgres user,
> and print a warning or refuse to start up if they are.
>
Ugh, please let's not do this. This was bouncing around in my head last
night, and this is
My mistake. Attached please find version 3, which should hopefully make
cfbot happy again.
pgbench.dash.d.or.not.dash.d.v3.patch
Description: Binary data
On Thu, Mar 21, 2024 at 6:20 PM Peter Eisentraut
wrote:
> lines are supposed to align vertically. With your patch, the first line
> would have variable length depending on the command.
>
Yes, that is a good point. Aligning those would be quite tricky, what if we
just kept a standard width for t
On Fri, Mar 22, 2024 at 11:39 AM David Christensen
wrote:
> I think it's easier to keep the widths balanced than constant (patch
> version included here)
Yeah, I'm fine with that, especially because nobody is translating it, nor
are they likely to, to be honest.
Cheers,
Greg
>
> The purpose of the setting is to prevent accidental
> modifications via ALTER SYSTEM in environments where
The emphasis on 'accidental' seems a bit heavy here, and odd. Surely, just
"to prevent modifications via ALTER SYSTEM in environments where..." is
enough?
Cheers,
Greg
On Mon, Apr 1, 2024 at 7:54 PM Robert Haas wrote:
> What I think we're mostly doing in the regression tests is shutting
> off every relevant type of plan except one. I theorize that what we
> actually want to do is tell the planner what we do want to happen,
> rather than what we don't want to ha
On Wed, Apr 3, 2024 at 3:21 PM Robert Haas wrote:
> It's also pretty clear to me that the fact that enable_indexscan
> and enable_indexonlyscan work completely differently from each other
> is surprising at best, wrong at worst, but here again, what this patch
> does about that is not above repro
On Thu, Apr 4, 2024 at 2:23 PM Bruce Momjian wrote:
> -end-of-life (EOL) and no longer supported.
> +after its initial release. After this, a final minor version will be
> released
> +and the software will then be unsupported (end-of-life).
Would be a shame to lose the EOL acronym.
+Such upgra
>
> It would be better if we created the required test files as part of the
> test run. (Why not? Too slow?) Alternatively, I have been thinking
> that maybe we could make the output more reproducible by messing with
> whatever random seed OpenSSL uses. Or maybe use a Python library to
> create
Patch looks good to me. Great idea overall, that forced regex has always
bugged me.
+ char *regexChars = "|*+?()[]{}.^$\\";
One super minor optimization is that we technically do not need to scan for
')' and ']'. If they appear without their partner, the query will fail
anyway. :)
Ch
+1 on the general idea. Maybe make that COPYRIGHT link go to an absolute
URI, like all the other links, in case this file gets copied somewhere?
Perhaps point it to https://www.postgresql.org/about/licence/
Cheers,
Greg
Attached please find a patch to adjust the behavior of the pgbench program
and make it behave like the other programs that connect to a database
(namely, psql and pg_dump). Specifically, add support for using -d and
--dbname to specify the name of the database. This means that -d can no
longer be u
On Tue, Mar 5, 2024 at 7:55 AM Laurenz Albe
wrote:
> My experience from the field is that a lot of log spam looks like
>
> database/table/... "xy" does not exist
> duplicate key value violates unique constraint "xy"
Forcibly hiding those at the Postgres level seems a heavy hammer for what
i
Someone on -general was asking about this, as they are listening on
multiple IPs and would like to know which exact one clients were hitting. I
took a quick look and we already have that information, so I grabbed some
stuff from inet_server_addr and added it as part of a "%L" (for 'local
interface'
On Mon, Mar 11, 2024 at 4:38 PM Bruce Momjian wrote:
> https://www.postgresql.org/support/versioning/
>
> This web page should correct the idea that "upgrades are more risky than
> staying with existing versions". Is there more we can do? Should we have
> a more consistent response for
Please find attached a patch to provide some basic ordering to the system
views pg_available_extensions and pg_available_extension_versions. It is
sorely tempting to add ORDER BYs to many of the other views in that file,
but I understand that would be contentious as there are reasons for not
adding
The use of the --echo-hidden flag in psql is used to show people the way
psql performs its magic for its backslash commands. None of them has more
magic than "\d relation", but it suffers from needing a lot of separate
queries to gather all of the information it needs. Unfortunately, those
queries
Seems to be some resistance to getting this in core, so why not just use an
extension? I was able to create a quick POC to do just that. Hook into PG
and look for AlterSystemStmt, throw a "Sorry, ALTER SYSTEM is not currently
allowed" error. Put into shared_preload_libraries and you're done. As a
b
On Tue, Jul 4, 2023 at 9:47 PM torikoshia
wrote:
> Since it seems preferable to have consistent line break policy and some
> people use 80-column terminal, wouldn't it be better to make all commands
> in 80
> columns per line?
>
All this seems an awful lot of work to support this mythical 80-col
On Fri, Sep 15, 2023 at 11:11 AM torikoshia
wrote:
> I do not intend to adhere to this rule(my terminals are usually bigger
> than 80 chars per line), but wouldn't it be a not bad direction to use
> 80 characters for all commands?
>
Well, that's the question du jour, isn't it? The 80 character l
Also a reluctant -1, as the comment-at-EOL style is very rare in my
experience over the years of seeing many a pg_hba file.
The attached patch makes an optimization to pg_checksums which prevents
rewriting the block if the checksum is already what we expect. This can
lead to much faster runs in cases where it is already set (e.g. enabled ->
disabled -> enable, external helper process, interrupted runs, future
parallel p
Thanks for the quick replies, everyone.
On Wed, May 26, 2021 at 10:17 PM Michael Paquier
wrote:
>
> -if (do_sync)
> +if (do_sync && total_files_modified)
> Here, I am on the edge. It could be an advantage to force a flush of
> the data folder anyway, no?
I was originally on the fence
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
Looks fine to me
The new status of this patch is: Ready for
Overall the patch looks good, but I did notice a few small things:
1. In pg_dumpall.c, the section /* Add long options to the pg_dump argument
list */, we are now
passing along the --drop-cascade option. However, --clean is not passed in, so
any call to pg_dumpall using --drop-cascade fails a
s/Node/Note/
Other than that, +1 to the patch and +1 to backpatching.
The new status of this patch is: Waiting on Author
Fair enough; thanks for the feedback. Attached is a new version that does
an unconditional sync (well, unless do_sync is false, a flag I am not
particularly fond of).
Cheers,
Greg
pg_checksums.optimize.writes.always.sync.patch
Description: Binary data
Newer version attach that adds a small documentation tweak as well.
Cheers,
Greg
pg_checksums.optimize.writes.and.always.sync.patch
Description: Binary data
Should we say "currently has"?
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
Latest patch looks fine to me, to be clear.
The new status of this patch is:
On Fri, Jun 18, 2021 at 1:57 AM Michael Paquier wrote:
> This doc addition is a bit confusing, as it could mean that each file
> has just one single checksum. We could be more precise, say:
> "When enabling checksums, each relation file block with a changed
> checksum is rewritten in place."
>
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: tested, failed
Spec compliant: not tested
Documentation:not tested
Looks fine to me, as a way of catching this edge case.
Those code comments look good.
On Tue, Jun 29, 2021 at 2:59 AM Michael Paquier wrote:
> Does that look fine to you?
>
Looks great, I appreciate the renaming.
Cheers,
Greg
Quick patch to add mention of the need for compiling with
--enable-tap-tests on the TAP section page
https://www.postgresql.org/docs/current/regress-tap.html
Searching about the TAP tests often leads to this page, but there is no
easy link or mention of the fact that the sample invocations will n
Some super quick nitpicks; feel free to ignore/apply/laugh off.
...
administrators to deploy their data-backed applications. PostgreSQL
continues to
add innovations on complex data types, including more conveniences for
accessing
JSON and support for noncontiguous ranges of data. This latest relea
On Sat, Aug 7, 2021 at 2:01 PM Bossart, Nathan wrote:
> Here is a rebased version of the patch.
>
Giving this a review.
Patch applies cleanly and `make check` works as of
e12694523e7e4482a052236f12d3d8b58be9a22c
Overall looks very nice and tucks MaxBackends safely away.
I have a few suggestion
Apologies, just saw this. I found no problems, those "failures" were just
me missing checkboxes on the commitfest interface. +1 on the patch.
Cheers,
Greg
On Fri, Jul 16, 2021 at 9:40 AM Tom Lane wrote:
> That would require pg_restore to try to edit the DROP commands during
> restore, which sounds horribly fragile. I'm inclined to think that
> supporting this option only during initial dump is safer.
>
Safer, but not nearly as useful. Maybe see w
On Mon, Aug 9, 2021 at 8:22 PM Bossart, Nathan wrote:
> > Is this going to get tripped by a call from restore_backend_variables?
>
> I ran 'make check-world' with EXEC_BACKEND with no problems, so I
> don't think so.
>
v3 looks good, but I'm still not sure how to test the bit mentioned above.
I'
On Wed, Aug 11, 2021 at 10:08 AM Tom Lane wrote:
> You must not have enabled EXEC_BACKEND properly. It's a compile-time
> #define that affects multiple modules, so it's easy to get wrong.
> The way I usually turn it on is
>
Thank you. I was able to get it all working, and withdraw any objection
On Wed, Aug 11, 2021 at 10:53 PM Wu Haotian wrote:
> Maybe we can add checks like "option --clean requires plain text format"?
> If so, should I start a new mail thread for this?
>
Shrug. To me, that seems related enough it could go into the existing
patch/thread.
Cheers,
Greg
Please find attached a quick patch to prevent this particularly bad error
message for running "postgres", when making the common mistake of
forgetting to put the "--single" option first because you added an earlier
arg (esp. datadir)
Current behavior:
$ ~/pg/bin/postgres -D ~/pg/data --single
202
On Wed, Jun 5, 2024 at 3:18 PM Nathan Bossart
wrote:
> Could we remove the requirement that --single must be first? I'm not
> thrilled about adding a list of "must be first" options that needs to stay
> updated, but given this list probably doesn't change too frequently, maybe
> that's still bet
On Wed, Jun 5, 2024 at 9:03 PM Robert Haas wrote:
> It's a funny use of "max" and "min", because the max is really what we're
> trying to do and the min is what we end
> up with, and those terms don't necessarily bring those ideas to mind.
requested_protocol_version and minimum_protocol_versio
On Thu, Jun 13, 2024 at 9:38 AM Robert Haas wrote:
> I agree with you, but I'm skeptical that solving it will be as easy as
> switching to Python. For whatever reason, it seems like every piece of
> infrastructure that the PostgreSQL community has suffers from severe
> neglect. Literally everythi
On Thu, Jun 13, 2024 at 1:08 PM Jelte Fennema-Nio
wrote:
> But Perl is at the next level of unmaintained infrastructure. It is
> actually clear how you can contribute to it, but still no new
> community members actually want to contribute to it. Also, it's not
> only unmaintained by us but it's a
On Sat, Jun 15, 2024 at 12:48 PM Jelte Fennema-Nio
wrote:
> Afaict, there's a significant part of our current community who feel the
> same way (and I'm pretty sure every sub-30 year old person who
> newly joins the community would feel the exact same way too).
>
Those young-uns are also the sam
On Fri, Jun 14, 2024 at 5:09 PM Jelte Fennema-Nio
wrote:
> Test::More on the other hand, while indeed still maintained, it's
> definitely not getting significant new feature development or
> improvements[2]. Especially when comparing it to pytest[3].
>
That's fair, although it's a little hard to
On Mon, Jun 17, 2024 at 3:39 PM Robert Haas wrote:
> So, a very simple algorithm would be: If the maximum number of workers
> have been running continuously for more than, say,
> 10 minutes, assume we're falling behind
Hmm, I don't know about the validity of this. I've seen plenty of cases
wher
If I am reading your patch correctly, we have lost the behavior of least
surprise in which the first "meta" argument overrides all others:
$ bin/postgres --version --boot --extrastuff
postgres (PostgreSQL) 16.2
What about just inlining --version and --help e.g.
else if (strcmp(argv[i], "--versio
51e5ead79f1c1b230b5b2d364 Mon Sep 17 00:00:00 2001
From: Greg Sabino Mullane
Date: Tue, 2 Jul 2024 15:13:44 -0400
Subject: [PATCH] Add new parameter log_duration_destination
This allows writing of items from log_min_duration_statement to be sent to separate log files.
---
doc/src/sgml/config.sgml
Thanks for the review. Please find attached a new version with proper tabs
and indenting.
Cheers,
Greg
0002-Add-local-address-to-log_line_prefix.patch
Description: Binary data
On Thu, Jul 11, 2024 at 6:47 AM Alastair Turner wrote:
> The other category of logging which would benefit from a separate file is
> audit. It also can create massive volumes of log content. Splitting audit
> information off into a separate file for use by a separate team or function
> is also a
This has been a long-standing annoyance of mine. Who hasn't done something
like this?:
psql> SET random_page_cost = 2.5;
(do some stuff, realize that rpc was too high)
Let's put that inside of postgresql.conf:
#--
# CUST
On Tue, Jul 11, 2023 at 11:04 AM Isaac Morland
wrote:
> Please, no!
>
> There is no end to accepting sloppy syntax. What next, allow "SET
> random_page_cost = 2.5;" (with or without semicolon) in config files?
>
Well yes, there is an end. A single, trailing semicolon. Full stop. It's
not a slipp
Please find attached a patch to jumble savepoint name, to prevent certain
transactional commands from filling up pg_stat_statements.
This has been a problem with some busy systems that use django, which likes
to wrap everything in uniquely named savepoints. Soon, over 50% of
your pg_stat_statements
On Mon, Jul 24, 2023 at 6:46 PM Michael Paquier wrote:
> Shouldn't this new field be marked as query_jumble_location
>
Yes, it should. I had some trouble getting it to work that way in the first
place, but now I realize it was just my unfamiliarity with this part of the
code. So thanks for the h
Thank you for the feedback, everyone. Attached is version 4 of the patch,
featuring a few tests and minor rewordings.
Cheers,
Greg
psql_watch_exit_on_zero_rows_v4.patch
Description: Binary data
On Tue, Apr 23, 2024 at 6:06 PM Tom Lane wrote:
> This change seems like a good thing anyway for anyone who's tempted
> to use "make dist" manually, since they wouldn't necessarily want
> to package HEAD either. Now, if we just do it exactly like that
> then trying to "make dist" without setting
Thank you for taking the time to review this. I've attached a new rebased
version, which has no significant changes.
> There is a comment in the patch that states:
>
> /* We do not need clean_ipv6_addr here: just report verbatim */
>
> I am not quite sure what it means, but I am guessing it means
On Fri, May 17, 2024 at 7:11 AM Tomas Vondra
wrote:
> It does seem to me a part of the solution needs to be helping to get
> those patches reviewed. I don't know how to do that, but perhaps there's
> a way to encourage people to review more stuff, or review stuff from a
> wider range of contribut
acfa4fc3749f987b272 Mon Sep 17 00:00:00 2001
From: Greg Sabino Mullane
Date: Fri, 24 May 2024 11:25:48 -0400
Subject: [PATCH] Add local address to log_line_prefix
---
doc/src/sgml/config.sgml | 5
src/backend/utils/error/elog.c| 25 +
Attached is a patch to allow a new behavior for the \watch command in psql.
When enabled, this instructs \watch to stop running once the query returns
zero rows. The use case is the scenario in which you are watching the
output of something long-running such as pg_stat_progress_create_index, but
on
On Sat, Jun 3, 2023 at 5:58 PM Michael Paquier wrote:
>
> Wouldn't something like a target_rows be more flexible? You could use
> this parameter with a target number of rows to expect, zero being one
> choice in that.
>
Thank you! That does feel better to me. Please see attached a new v2 patch
On Thu, Jun 8, 2023 at 8:44 AM Hannu Krosing wrote:
> Do we have any statistics for the distribution of our user base ?
>
> My gut feeling says that for performance-critical use the non-Linux is
> in low single digits at best.
>
Stats are probably not possible, but based on years of consulting,
On Thu, Jun 15, 2023 at 4:16 AM Vladimir Churyukin
wrote:
> We're trying to see what is the worst performance in terms of I/O, i.e.
>> when the database just started up or the data/indexes being queried are not
>> cached at all.
>
>
You could create new tables that are copies of the existing ones
>
> So I decided to propose a simple transform extension to pass bytea as
> native Perl octet strings.
Quick review, mostly housekeeping things:
* Needs a rebase, minor failure on Mkvcbuild.pm
* Code needs standardized formatting, esp. bytea_plperl.c
* Needs to be meson-i-fied (i.e. add a "meson
Thanks for the feedback!
On Wed, Jul 5, 2023 at 5:51 AM Daniel Gustafsson wrote:
>
> The comment on ExecQueryAndProcessResults() needs to be updated with an
> explanation of what this parameter is.
>
I added a comment in the place where min_rows is used, but not sure what
you mean by adding it
Rebased and reworked patches attached:
v2-0001-Add-new-initdb-argument-no-data-checksums-to-force-checksums-off.patch
- Adds --no-data-checksums to initdb.c, adjusts --help and sgml docs, adds
simple tests
v2-0002-Allow-tests-to-force-checksums-off-when-calling-init.patch
- Adjusts the Perl tests
I'm not opposed to this new method, as long as the error code improves. :)
+typedef enum Subprogram
+{
+ SUBPROGRAM_CHECK,
+ SUBPROGRAM_BOOT,
+#ifdef EXEC_BACKEND
+ SUBPROGRAM_FORKCHILD,
+#endif
I'm not happy about making this and the const char[] change their structure
based on the ifdefs - coul
On Mon, Aug 26, 2024 at 3:46 PM Nathan Bossart
wrote:
> Should we error if both --data-checksum and --no-data-checksums are
> specified? IIUC with 0001, we'll use whichever is specified last.
>
Hmmm, that is a good question. We have never (to my recollection) flipped a
default quite like this b
On Mon, Aug 26, 2024 at 11:43 AM Nathan Bossart
wrote:
> On Sun, Aug 25, 2024 at 01:14:36PM -0400, Greg Sabino Mullane wrote:
> > I'm not happy about making this and the const char[] change their
> structure
> > based on the ifdefs - could we not just leave forkchi
I normally wouldn't mention my blog entries here, but this one was about
the hackers mailing list, so wanted to let people know about it in case you
don't follow Planet Postgres. I scanned the last year's worth of posts and
gathered the most used acronyms and jargon. The most commonly used acronym
On Tue, Sep 3, 2024 at 11:50 AM Nathan Bossart
wrote:
> Do you think these acronyms make it difficult for some to contribute to
> Postgres? I've always felt that they were pretty easy to figure out and a
> nice way to save some typing for common phrases, but I'm not sure it's ever
> really been
Thanks for everyone's work on this, I am very interested in it getting into
a release. What is the status of this?
My use case is Patroni - when it needs to do a failover, it shuts down the
primary. However, large transactions can cause it to stay in the "shutting
down" state for a long time, whic
>
> Are there any others who have an opinion on this?
Big +1 to having it on by default. It's already one of the first things I
turn on by default on any system I come across. The log spam is minimal,
compared to all the other stuff that ends up in there. And unlike most of
that stuff, this is ou
I saw a database recently where some app was inserting the source port into
the application_name field, which meant that pg_stat_statements.max was
quickly reached and queries were simply pouring in and out of
pg_stat_statements, dominated by some "SET application_name = 'myapp
10.0.0.1:1234'" call
pression is better than in the past, vacuum is better now,
and data-checksums being on is such a complete default in the wild, it
feels weird and a disservice that we are not running all our tests like
that.
Cheers,
Greg
From 12ce067f5ba64414d1d14c5f2e763d04cdfacd13 Mon Sep 17 00:00:00 2001
From: Greg Sa
On Wed, Aug 7, 2024 at 4:43 AM Michael Banck wrote:
> I think the last time we dicussed this the consensus was that
> computational overhead of computing the checksums is pretty small for
> most systems (so the above change seems warranted regardless of whether
> we switch the default), but turni
Thank you for the feedback. Please find attached three separate patches.
One to add a new flag to initdb (--no-data-checksums), one to adjust the
tests to use this flag as needed, and the final to make the actual switch
of the default value (along with tests and docs).
Cheers,
Greg
0001-Add-new-
Sounds like a good idea. You probably want to ask on pgsql-www. I imagine
it would have to be coded against this:
https://git.postgresql.org/gitweb/?p=pgweb.git
A working patch would probably be nice to get things started. but I
recognize it's a little bit of chicken-and-egg.
Cheers,
Greg
On Thu, Aug 8, 2024 at 6:11 AM Peter Eisentraut
wrote:
> My understanding was that the reason for some hesitation about adopting
> data checksums was the performance impact. Not the checksumming itself,
> but the overhead from hint bit logging. The last time I looked into that,
> you could get
Now that I've spent some time away from this, I'm reconsidering why we are
going through all the trouble of semi-jumbling SET statements. Maybe we
just keep it simple and everything becomes "SET myvar = $1" or even "SET
myvar" full stop? I'm having a hard time finding a real-world situation in
whic
On Tue, Jul 23, 2024 at 9:37 AM David Christensen wrote:
> I'm not married to the exact syntax of this feature; anything else short
> and consistent could work if `ALL` is considered to potentially
> gain a different interpretation in the future.
>
GROUP BY *
Just kidding. But a big +1 to the w
1 - 100 of 198 matches
Mail list logo
