Re: First draft of PG 17 release notes

Bruce Momjian wrote: > have committed the first draft of the PG 17 release notes; you can > see the results here: > > https://momjian.us/pgsql_docs/release-17.html In the psql items, I'd suggest mentioning https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=90f5178

Re: Support LIKE with nondeterministic collations

Peter Eisentraut wrote: > However, off the top of my head, this definition has three flaws: (1) > It would make the single-character wildcard effectively an > any-number-of-characters wildcard, but only in some circumstances, which > could be confusing, (2) it would be difficult to

Re: Support LIKE with nondeterministic collations

Peter Eisentraut wrote: > Yes, certainly, and there is also no indexing support (other than for > exact matches). The ICU docs have this note about prefix matching: https://unicode-org.github.io/icu/userguide/collation/architecture.html#generating-bounds-for-a-sort-key-prefix-matching

Re: Support LIKE with nondeterministic collations

Peter Eisentraut wrote: > This patch adds support for using LIKE with nondeterministic > collations. So you can do things such as > > col LIKE 'foo%' COLLATE case_insensitive Nice! > The pattern is partitioned into substrings at wildcard characters > (so 'foo%bar' is partitioned

Re: psql's FETCH_COUNT (cursor) is not being respected for CTEs

Alexander Lakhin wrote: > >> Now that ExecQueryUsingCursor() is gone, it's not clear, what does > >> the following comment mean:? > >> * We must turn off gexec_flag to avoid infinite recursion. Note that > >> * this allows ExecQueryUsingCursor to be applied to the individual >

Re: psql's FETCH_COUNT (cursor) is not being respected for CTEs

Tom Lane wrote: > I've reconsidered after realizing that implementing FETCH_COUNT > atop traditional single-row mode would require either merging > single-row results into a bigger PGresult or persuading psql's > results-printing code to accept an array of PGresults not just > one.

Re: Fixing backslash dot for COPY FROM...CSV

Tom Lane wrote: > This is sufficiently weird that I'm starting to come around to > Daniel's original proposal that we just drop the server's recognition > of \. altogether (which would allow removal of some dozens of lines of > complicated and now known-buggy code) FWIW my plan was to

Re: Fixing backslash dot for COPY FROM...CSV

Tom Lane wrote: > Not sure what to do here. One idea is to install just the psql-side > fix, which should break nothing now that version-2 protocol is dead, > and then wait a few years before introducing the server-side change. > That seems kind of sad though. Wouldn't backpatching

Re: Fixing backslash dot for COPY FROM...CSV

Tom Lane wrote: > I've looked over this patch and I generally agree that this is a > reasonable solution. Thanks for reviewing this! > I'm also wondering why the patch adds a test for > "PQprotocolVersion(conn) >= 3" in handleCopyIn. I've removed this in the attached update. > I

Re: psql's FETCH_COUNT (cursor) is not being respected for CTEs

Tom Lane wrote: > > I should say that I've noticed significant latency improvements with > > FETCH_COUNT retrieving large resultsets, such that it would benefit > > non-interactive use cases. > > Do you have a theory for why that is? It's pretty counterintuitive > that it would help at

Re: psql's FETCH_COUNT (cursor) is not being respected for CTEs

Tom Lane wrote: > I do not buy that psql's FETCH_COUNT mode is a sufficient reason > to add it. FETCH_COUNT mode is not something you'd use > non-interactively I should say that I've noticed significant latency improvements with FETCH_COUNT retrieving large resultsets, such that it

Re: psql's FETCH_COUNT (cursor) is not being respected for CTEs

Laurenz Albe wrote: > Here is the code review for patch number 2: > +static void > +CloseGOutput(FILE *gfile_fout, bool is_pipe) > > It makes sense to factor out this code. > But shouldn't these functions have a prototype at the beginning of the file? Looking at the other static

Re: psql's FETCH_COUNT (cursor) is not being respected for CTEs

Laurenz Albe wrote: > I had a look at patch 0001 (0002 will follow). Thanks for reviewing this! I've implemented the suggested doc changes. A patch update will follow with the next part of the review. > > --- a/src/interfaces/libpq/fe-exec.c > > +++ b/src/interfaces/libpq/fe-exec.c > >

Re: Built-in CTYPE provider

Jeff Davis wrote: > The tests include initcap('123abc') which is '123abc' in the PG_C_UTF8 > collation vs '123Abc' in PG_UNICODE_FAST. > > The reason for the latter behavior is that the Unicode Default Case > Conversion algorithm for toTitlecase() advances to the next Cased > character

Re: psql's FETCH_COUNT (cursor) is not being respected for CTEs

Jakub Wartak wrote: > when I run with default pager (more or less): > \set FETCH_COUNT 1000 > WITH data AS (SELECT generate_series(1, 2000) as Total) select > repeat('a',100) || data.Total || repeat('b', 800) as total_pat from > data; > -- it enters pager, a skip couple of pages and

Re: psql's FETCH_COUNT (cursor) is not being respected for CTEs

vignesh C wrote: > patching file src/interfaces/libpq/exports.txt > Hunk #1 FAILED at 191. > 1 out of 1 hunk FAILED -- saving rejects to file > src/interfaces/libpq/exports.txt.rej > > Please post an updated version for the same. PFA a rebased version. Best regards, -- Daniel Vérité

Re: Fixing backslash dot for COPY FROM...CSV

Robert Haas wrote: > Those links unfortunately seem not to be entirely specific to this > issue. Other, related things seem to be discussed there, and it's not > obvious that everyone agrees on what to do, or really that anyone > agrees on what to do. The best link that I found for this

Re: Built-in CTYPE provider

Peter Eisentraut wrote: > > If the Postgres default was bytewise sorting+locale-agnostic > > ctype functions directly derived from Unicode data files, > > as opposed to libc/$LANG at initdb time, the main > > annoyance would be that "ORDER BY textcol" would no > > longer be the

Re: Fixing backslash dot for COPY FROM...CSV

Robert Haas wrote: > Part of my hesitancy, I suppose, is that I don't > understand why we even have this strange convention of making \. > terminate the input in the first place -- I mean, why wouldn't that be > done in some kind of out-of-band way, rather than including a special >

Re: Built-in CTYPE provider

Jeff Davis wrote: > New version attached. [v16] Concerning the target category_test, it produces failures with versions of ICU with Unicode < 15. The first one I see with Ubuntu 22.04 (ICU 70.1) is: category_test: Postgres Unicode version:15.1 category_test: ICU Unicode

Re: Built-in CTYPE provider

Jeff Davis wrote: > > Jeremy also raised a problem with old versions of psql connecting to > > a > > new server: the \l and \dO won't work. Not sure exactly what to do > > there, but I could work around it by adding a new field rather than > > renaming (though that's not ideal). > > I

Re: Built-in CTYPE provider

Jeff Davis wrote: > Attached a more complete version that fixes a few bugs [v15 patch] When selecting the builtin provider with initdb, I'm getting the following setup: $ bin/initdb --locale=C.UTF-8 --locale-provider=builtin -D/tmp/pgdata The database cluster will be initialized

Re: psql's FETCH_COUNT (cursor) is not being respected for CTEs

Hi, PFA a rebased version. Best regards, -- Daniel Vérité https://postgresql.verite.pro/ Twitter: @DanielVerite From cd0fe1d517a0e31e031fbbea1e603a715c77ea97 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Daniel=20V=C3=A9rit=C3=A9?= Date: Tue, 2 Jan 2024 14:15:48 +0100 Subject: [PATCH v5 1/2]

Re: Fixing backslash dot for COPY FROM...CSV

Hi, The CI patch tester fails on this patch, because it has a label at the end of a C block, which I'm learning is a C23 feature that happens to be supported by gcc 11 [1], but is not portable. PFA an update fixing this, plus removing an obsolete chunk in the COPY documentation that v2 left

Re: Built-in CTYPE provider

Robert Haas wrote: > For someone who is currently defaulting to es_ES.utf8 or fr_FR.utf8, > a change to C.utf8 would be a much bigger problem, I would > think. Their alphabet isn't in code point order, and so things would > be alphabetized wrongly. > That might be OK if they don't care

Re: Fixing backslash dot for COPY FROM...CSV

vignesh C wrote: > Thanks for the updated patch, any reason why this is handled only in csv. > postgres=# copy test1 from '/home/vignesh/postgres/inst/bin/copy1.out'; > COPY 1 > postgres=# select * from test1; > c1 > --- > line1 > (1 row) I believe it's safer to not change anything

Re: Built-in CTYPE provider

Jeff Davis wrote: > But there are a lot of users for whom neither of those things are true, > and it makes zero sense to order all of the text indexes in the > database according to any one particular locale. I think these users > would prioritize stability and performance for the

Re: Fixing backslash dot for COPY FROM...CSV

vignesh C wrote: > I noticed that these tests are passing without applying patch too: > +insert into copytest2(test) values('line1'), ('\.'), ('line2'); > +copy (select test from copytest2 order by test collate "C") to :'filename' > csv; > +-- get the data back in with copy > +truncate

Fixing backslash dot for COPY FROM...CSV

Hi, PFA a patch that attempts to fix the bug that \. on a line by itself is handled incorrectly by COPY FROM ... CSV. This issue has been discussed several times previously, for instance in [1] and [2], and mentioned in the doc for \copy in commit 42d3125. There's one case that works today:

Re: Built-in CTYPE provider

Jeff Davis wrote: > While "full" case mapping sounds more complex, there are actually > very few cases to consider and they are covered in another (small) > data file. That data file covers ~100 code points that convert to > multiple code points when the case changes (e.g. "ß" -> "SS"), 7

Re: Emitting JSON to file using COPY TO

Dave Cramer wrote: > > This argument for leaving 3 as the column count makes sense to me. I > > agree this content is not meant to facilitate interpreting the contents at > > a protocol level. > > > > I'd disagree. From my POV if the data comes back as a JSON Array this is > one object

Re: Emitting JSON to file using COPY TO

Joe Conway wrote: > copyto_json.007.diff When the source has json fields with non-significant line feeds, the COPY output has these line feeds too, which makes the output incompatible with rule #2 at https://jsonlines.org ("2. Each Line is a Valid JSON Value"). create table j(f json);

Re: Emitting JSON to file using COPY TO

Joe Conway wrote: > The attached should fix the CopyOut response to say one column. I.e. it > ought to look something like: Spending more time with the doc I came to the opinion that in this bit of the protocol, in CopyOutResponse (B) ... Int16 The number of columns in the data to be

Re: Emitting JSON to file using COPY TO

Andrew Dunstan wrote: > IMNSHO, we should produce either a single JSON > document (the ARRAY case) or a series of JSON documents, one per row > (the LINES case). "COPY Operations" in the doc says: " The backend sends a CopyOutResponse message to the frontend, followed by zero or

Re: Make COPY format extendable: Extract COPY TO format implementations

Sutou Kouhei wrote: > * 2022-04: Apache Arrow [2] > * 2018-02: Apache Avro, Apache Parquet and Apache ORC [3] > > (FYI: I want to add support for Apache Arrow.) > > There were discussions how to add support for more formats. [3][4] > In these discussions, we got a consensus about making

Re: EXCLUDE COLLATE in CREATE/ALTER TABLE document

shihao zhong wrote: > Thanks for your comments, a new version is attached. In this hunk: @@ -1097,8 +1097,8 @@ WITH ( MODULUS numeric_literal, REM method index_method. The operators are required to be commutative. Each exclude_element - can optionally specify

Re: proposal: change behavior on collation version mismatch

Jeremy Schneider wrote: > 1) "collation changes are uncommon" (which is relatively correct) > 2) "most users would rather have ease-of-use than 100% safety, since > it's uncommon" > > And I think this led to the current behavior of issuing a warning rather > than an error, There's a

Re: [ psql - review request ] review request for \d+ tablename, \d+ indexname indenting

Shlok Kyal wrote: > > The error was corrected and a new diff file was created. > > The diff file was created based on 16 RC1. > > We confirmed that 5 places where errors occurred when performing > > make check were changed to ok. Reviewing the patch, I see these two problems in the

Re: psql's FETCH_COUNT (cursor) is not being respected for CTEs

Hi, Here's a new version to improve the performance of FETCH_COUNT and extend the cases when it can be used. Patch 0001 adds a new mode in libpq to allow the app to retrieve larger chunks of results than the single row of the row-by-row mode. The maximum number of rows per PGresult is set by

Re: Does UCS_BASIC have the right CTYPE?

Peter Eisentraut wrote: > > That seems to suggest the standard answer should be 'Á' regardless of > > any COLLATE clause (though I could be misreading). I'm a bit confused > > by that... what's the standard-compatible way to specify the locale for > > UPPER()/LOWER()? If there is none,

Re: Pre-proposal: unicode normalized text

Jeff Davis wrote: > I believe the patch has utility as-is, but I've been brainstorming a > few more ideas that could build on it: > > * Add a per-database option to enforce only storing assigned unicode > code points. There's a problem in the fact that the set of assigned code points is

Re: EBCDIC sorting as a use case for ICU rules

Peter Eisentraut wrote: > Committed with some editing. I moved the existing rules example from > the CREATE COLLATION page into the new section you created, so we have a > simple example followed by the complex example. OK, thanks for pushing this! Best regards, -- Daniel Vérité

Re: psql's FETCH_COUNT (cursor) is not being respected for CTEs

Tom Lane wrote: > This gives me several "-Wincompatible-pointer-types" warnings > [...] > I think what you probably ought to do to avoid all that is to change > the arguments of PrintQueryResult and nearby routines to be "const > PGresult *result" not just "PGresult *result". The

Re: pg_collation.collversion for C.UTF-8

Thomas Munro wrote: > What could we do that would be helpful here, without affecting users > of the "true" C.UTF-8 for the rest of time? This is a Debian (+ > downstream distro) only problem as far as we know so far, and only > for Debian 11 and older. It seems to include RedHat-based

EBCDIC sorting as a use case for ICU rules

Hi, In the "Order changes in PG16 since ICU introduction" discussion, one sub-thread [1] was about having a credible use case for tailoring collations with custom rules, a new feature in v16. At a conference this week I was asked if ICU could be able to sort like EBCDIC [2]. It turns out it has

Re: Order changes in PG16 since ICU introduction

Jeff Davis wrote: > I guess where I'm confused is: why would a user actually want their > database collation to be C.UTF-8? It's slower than C, our > implementation doesn't properly version it (as you pointed out), and > the semantics don't seem great ('Z' < 'a'). Because when

Re: Order changes in PG16 since ICU introduction

Jeff Davis wrote: > I implemented a compromise where initdb will > change C.UTF-8 to the built-in provider This handling of C.UTF-8 would be felt by users as simply broken. With the v10 patches: $ initdb --locale=C.UTF-8 initdb: using locale provider "builtin" for ICU locale

Re: Inconsistent results with libc sorting on Windows

Juan José Santamaría Flecha wrote: > Just to make sure we are all seeing the same problem, does the attached > patch fix your test? The problem of the random changes in sorting disappears for all libc locales in pg_collation, so this is very promising. However it persists for the

Re: Order changes in PG16 since ICU introduction

Jeff Davis wrote: > As I replied in that subthread, that creates a worse problem: if you > only change the provider when the locale is C, then what about when the > locale is *not* C? > > export LANG=en_US.UTF-8 > initdb -D data --locale=fr_FR.UTF-8 > ... >provider:icu >

Re: Order changes in PG16 since ICU introduction

Tatsuo Ishii wrote: > >> Yes it's a special case but when doing initdb --locale=C, a user does > >> not need or want an ICU locale. They want the same thing than what v15 > >> does with the same arguments: a template0 database with > >> datlocprovider='c', datcollate='C', datctype='C',

Re: Order changes in PG16 since ICU introduction

Jeff Davis wrote: > The locale "C" is a special case, documented as a non-locale. So, if > LOCALE/--locale apply to ICU, then either ICU needs to handle locale > "C" in the expected way (v8 patch series); or when we see locale "C" we > need to somehow change the provider into something

Re: pg_collation.collversion for C.UTF-8

I wrote: > Consider matching '\d' in a regexp. With C.UTF-8 (glibc-2.35), we > only match ASCII characters 0-9, or 10 codepoints. With > "en-US-u-va-posix-x-icu" we match 660 codepoints comprising all the > digit characters in all languages, plus a bunch of variants for > mathematical

Re: pg_collation.collversion for C.UTF-8

Jeff Davis wrote: > What about ICU? How should provider=icu locale=C.UTF-8 behave? We > could: > > a. Just pass it to the provider and see what happens (older versions of > ICU would interpret it as en-US-u-va-posix; newer versions would give > the root locale). > > b. Consistently

Re: Inconsistent results with libc sorting on Windows

Thomas Munro wrote: > > > Also, it does not occur at all if parallel scan is disabled. > > > > Could this be a clue that it is failing to be transitive? > > That vaguely rang a bell for me... and then I remembered this thread: > >

Re: Order changes in PG16 since ICU introduction

Jeff Davis wrote: > New patch series attached. I plan to commit 0001 and 0002 soon, unless > there are objections. > > 0001 causes the "C" and "POSIX" locales to be treated with > memcmp/pg_ascii semantics in ICU, just like in libc. We also > considered a new "none" provider, but it's

Inconsistent results with libc sorting on Windows

Hi, While trying pg16beta1 libc collations on Windows, I noticed that UTF-8 text sorts sometimes differently across invocations with the same locales, which is wrong since these collations are deterministic. The OS is Windows 10 Home, version 10.0.19045 Build 19045, self-built 16beta1 with VS

Re: pg_collation.collversion for C.UTF-8

Jeff Davis wrote: > > For libc: this change may affect any user who happened to have > > LANG=C.UTF-8 in their environment at initdb time, which is probably a > > lot of users, and some buildfarm members. However, the average risk > > seems to be much lower, because we've gone a long

Simplify pg_collation.collversion for Windows libc

Hi, Currently the libc collation version for Windows has two components coming from the NLSVERSIONINFOEX structure [1] dwNLSVersion and dwDefinedVersion So we get version numbers looking like this (with 16 beta1): postgres=# select collversion,count(*) from pg_collation group by collversion;

Re: Order changes in PG16 since ICU introduction

Jeff Davis wrote: > > #1 > > > > postgres=# create database test1 locale='fr_FR.UTF-8'; > > NOTICE: using standard form "fr-FR" for ICU locale "fr_FR.UTF-8" > > ERROR: new ICU locale (fr-FR) is incompatible with the ICU locale of > > I don't see a problem here. If you specify LOCALE

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

Kirk Wolak wrote: > We do NOT do "CSV", we mimic pg_dump. pg_dump uses the text format (as opposed to csv), where \. on a line by itself cannot appear in the data, so there's no problem. The problem is limited to the csv format. Best regards, -- Daniel Vérité

Re: Order changes in PG16 since ICU introduction

Jeff Davis wrote: > If we special case locale=C, but do nothing for locale=fr_FR, then I'm > not sure we've solved the problem. Andrew Gierth raised the issue here, > which he called "maximally confusing": > > https://postgr.es/m/874jp9f5jo@news-spur.riddles.org.uk > > That's why I

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

Joel Jacobson wrote: > Is there a valid reason why \. is needed for COPY FROM filename? > It seems to me it would only be necessary for the COPY FROM STDIN case, > since files have a natural end-of-file and a known file size. Looking at CopyReadLineText() over at [1], I don't see a

Re: Order changes in PG16 since ICU introduction

Jeff Davis wrote: > 2) Automatically change the provider to libc when locale=C. > > Almost works, but it's not clear how we handle the case "provider=icu > lc_collate='fr_FR.utf8' locale=C". > > If we change it to "provider=libc lc_collate=C", we've overridden the > specified

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

Joel Jacobson wrote: > I understand its necessity for STDIN, given that the end of input needs to > be explicitly defined. > However, for files, we have a known file size and the end-of-file can be > detected without the need for special markers. > > Also, is the difference in how

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

Joel Jacobson wrote: > I've been using that trick myself many times in the past, but thanks to this > deep-dive into this topic, it looks to me like TEXT would be a better format > fit when dealing with unquoted TSV files, or? > > OTOH, one would then need to inspect the TSV file doesn't

Re: Order changes in PG16 since ICU introduction

Jeff Davis wrote: > Attached are a few small patches: > > 0001: don't convert C to en-US-u-va-posix > 0002: handle locale C the same regardless of the provider, as you > suggest above > 0003: make LOCALE (or --locale) apply to everything including ICU Testing this briefly I

Re: Add standard collation UNICODE

Peter Eisentraut wrote: > COLLATE UNICODE > > instead of > > COLLATE "und-x-icu" > > or whatever it is, is pretty useful. > > So, attached is a small patch to add this. This collation has an empty pg_collation.collversion column, instead of being set to the same value as

Re: Order changes in PG16 since ICU introduction

Jeff Davis wrote: > > (I'm not sure whether those operations can get redirected to ICU > > today > > or whether they still always go to libc, but we'll surely want to fix > > it eventually if the latter is still true.) > > Those operations do get redirected to ICU today. FTR the full

Re: pg_collation.collversion for C.UTF-8

Thomas Munro wrote: > It looks like for technical reasons > inside glibc, that couldn't be done before 2.35: > > https://sourceware.org/bugzilla/show_bug.cgi?id=17318 > > That strengthens my opinion that C.UTF-8 (the real C.UTF-8 supplied > by the glibc project) isn't supposed to be

pg_collation.collversion for C.UTF-8

Hi, get_collation_actual_version() in pg_locale.c currently excludes C.UTF-8 (and more generally C.*) from versioning, which makes pg_collation.collversion being empty for these collations. char * get_collation_actual_version(char collprovider, const char *collcollate) { if

Re: TAP tests for psql \g piped into program

Peter Eisentraut wrote: > So for your patch, I would just do the path adjustment ad hoc in-line. > It's just one additional line. Here's the patch updated that way. Best regards, -- Daniel Vérité https://postgresql.verite.pro/ Twitter: @DanielVerite diff --git

Re: psql's FETCH_COUNT (cursor) is not being respected for CTEs

I wrote: > Here's a POC patch implementing row-by-row fetching. PFA an updated patch. Best regards, -- Daniel Vérité https://postgresql.verite.pro/ Twitter: @DanielVerite diff --git a/src/bin/psql/common.c b/src/bin/psql/common.c index f907f5d4e8..ad5e8a5de9 100644 ---

Re: Allow tailoring of ICU locales with custom rules

Peter Eisentraut wrote: [patch v5] Two quick comments: - pg_dump support need to be added for CREATE COLLATION / DATABASE - there doesn't seem to be a way to add rules to template1. If someone wants to have icu rules and initial contents to their new databases, I think they need to

Re: proposal: psql: psql variable BACKEND_PID

I wrote: > > In the varlistentry, I suggest we add "This variable is unset when the > > connection is lost." after "but can be changed or unset. > > Personally I'd much rather have BACKEND_PID set to 0 rather than being unset > when not connected. For one thing it allows safely using \if

Re: proposal: psql: psql variable BACKEND_PID

Corey Huinker wrote: > 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 Maybe something like this could be used, with no external action: postgres=# \echo

Re: Allow tailoring of ICU locales with custom rules

Laurenz Albe wrote: > Cool so far. Now I created a database with that locale: > > CREATE DATABASE teutsch LOCALE_PROVIDER icu ICU_LOCALE german_phone > LOCALE "de_AT.utf8" TEMPLATE template0; > > Now the rules are not in "pg_database": The parameter after ICU_LOCALE is passed

Re: psql's FETCH_COUNT (cursor) is not being respected for CTEs

Tom Lane wrote: > I agree that it seems like a good idea to try. > There will be more per-row overhead, but the increase in flexibility > is likely to justify that. Here's a POC patch implementing row-by-row fetching. If it wasn't for the per-row overhead, we could probably get rid of

Re: psql's FETCH_COUNT (cursor) is not being respected for CTEs

Jakub Wartak wrote: > It might be a not so well known fact (?) that CTEs are not executed > with cursor when asked to do so, but instead silently executed with > potential huge memory allocation going on. Patch is attached. My one > doubt is that not every statement starting with "WITH"

TAP tests for psql \g piped into program

Hi, This is a follow-up to commit d2a44904 from the 2022-11 CF [1] The TAP tests were left out with the suggestion to use Perl instead of cat (Unix) / findstr (Windows) as the program to pipe into. PFA a patch implementing that suggestion. [1] https://commitfest.postgresql.org/40/4000/ Best

Re: Tests for psql \g and \o

Michael Paquier wrote: > Thanks, the tests part of the main regression test suite look good to > me, so I have applied them after fixing a few typos and tweaking the > style of the test. Thanks! > Regarding the tests with pipes, I had cold feet with the > dependencies on cat for

Re: Tests for psql \g and \o

Michael Paquier wrote: > +psql_like($node, "SELECT 'one' \\g | cat >$g_file", qr//, "one command > \\g"); > +my $c1 = slurp_file($g_file); > +like($c1, qr/one/); > > Windows may not have an equivalent for "cat", no? Note that psql's > 001_basic.pl has no restriction in place for

Re: psql: Add command to use extended query protocol

Peter Eisentraut wrote: > > I assume that we may sometimes want to use the > > extended protocol on all queries of a script, like > > pgbench does with --protocol=extended. > > But is there an actual use case for this in psql? In pgbench, there are > scenarios where you want to test

Re: psql: Add command to use extended query protocol

Peter Eisentraut wrote: > Is there a use case for a global setting? I assume that we may sometimes want to use the extended protocol on all queries of a script, like pgbench does with --protocol=extended. Outside of psql, it's too complicated to parse a SQL script to replace the

Re: psql: Add command to use extended query protocol

David G. Johnston wrote: > I would keep the \gp meta-command to force extended mode regardless > of whether the query itself requires it. +1 > A pset variable to control the default seems reasonable as well. > The implication would be that if you set that pset variable there is > no way

Re: psql: Add command to use extended query protocol

Jehan-Guillaume de Rorthais wrote: > As I wrote in my TCE review, would it be possible to use psql vars to set > some > named parameters for the prepared query? This would looks like: > > \set p1 foo > \set p2 bar > SELECT :'p1', :'p2' \gp As I understand the feature, variables would

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

Corey Huinker wrote: > 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 \o, etc). If you see value in that > I can amend the patch. If the

Tests for psql \g and \o

Hi, Here's a patch adding regression tests for \g and \o, and TAP tests for \g | program, It's a follow up to the discussion at [1]. Since this discussion already has a slot in the CF [2] with a committed patch, let's start a new separate thread. [1]

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

Tom Lane wrote: > > Currently, test/regress/sql/psql.sql doesn't AFAICS write anything > > outside of stdout, but \g, \o, \copy need to write to external > > files to be tested properly. > > Yeah, I don't think we can usefully test these in psql.sql, because > file-system side effects

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

Tom Lane wrote: > Pushed after making some corrections. Thanks! > Given the time pressure, I did not worry about installing regression > test coverage for this stuff, but I wonder if we shouldn't add some. Currently, test/regress/sql/psql.sql doesn't AFAICS write anything outside of

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

Hi, The psql improvement in v15 to output multiple result sets does not behave as one might expect with \g: the output file or program to pipe into is opened/closed on each result set, overwriting the previous ones in the case of \g file. Example: psql -At

Re: Question about user/database-level parameters

Japin Li wrote: > However, if the database is in production, we cannot go into single-user > mode, should we provide an option to change this behavior on the fly? It already exists, through PGOPTIONS, which appears to work for local_preload_libraries, in a quick test. That is, you can

Re: Add header support to text format and matching feature

Julien Rouhaud wrote: > Maybe that's just me but I understand "not supported" as "this makes > sense, but this is currently a limitation that might be lifted > later". Looking at ProcessCopyOptions(), there are quite a few invalid combinations of options that produce

Re: Collation version tracking for macOS

Tom Lane wrote: > Yeah, and it's exactly at the level of quirks that things are likely > to change. Nobody's going to suddenly start sorting B before A. > They might, say, change their minds about where the digram "cz" > sorts relative to single letters, in languages where special rules

Re: Unicode Variation Selector and Combining character

Thomas Munro wrote: > Looking around a bit, it might be interesting to check if the > icu_character_boundaries() function in Daniel Vérité's icu_ext treats > IVSs as single grapheme clusters. It does. with strings(s) as ( values (U&'\+0066FE' || U&'\+0E0103'), (U&'\+00304B' ||

Re: ICU_LOCALE set database default icu collation but not working as intended.

jian he wrote: > - dbicu3, ICU_LOCALE 'en-u-kr-latn-digit-kf-upper-kn-true' seems > 'kf-upper' not grouped strings beginning with character 'A' together? You seem to expect that the sort algorithm takes characters from left to right, and when it compares 'A' and 'a', it will sort

Re: ICU_LOCALE set database default icu collation but not working as intended.

jian he wrote: > CREATE > DATABASE dbicu1 LOCALE_PROVIDER icu LOCALE 'en_US.UTF-8' ICU_LOCALE > 'en-u-kf-upper' TEMPLATE 'template0'; > CREATE DATABASE dbicu2 LOCALE_PROVIDER icu LOCALE 'en_US.UTF-8' ICU_LOCALE > 'en-u-kr-latn-digit' TEMPLATE 'template0'; > [...] > I am not sure this is

Re: variable filename for psql \copy

Jiří Fejfar wrote: > I have found maybe buggy behaviour (of psql parser?) when using psql \copy > with psql variable used for filename. While it's annoying that it doesn't work as you tried it, this behavior is documented, so in that sense it's not a bug. The doc also suggests a

Re: Add header support to text format and matching feature

Peter Eisentraut wrote: > - The DefGetCopyHeader() function seems very bulky and might not be > necessary. I think you can just check for the string "match" first and > then use defGetBoolean() as before if it didn't match. The problem is that defGetBoolean() ends like this in the

Re: ICU for global collation

Finnerty, Jim wrote: > In ICU, the "locale" is just the first part of what we can pass to the > "locale" parameter in CREATE COLLATION - the part before the optional '@' > delimiter. The ICU locale does not include the secondary or tertiary > properties, Why not? Please see

Re: ICU for global collation

Julien Rouhaud wrote: > > > While on that topic, the doc should probably mention that default ICU > > > collations can only be deterministic. > > > > Well, there is no option to do otherwise, so I'm not sure where/how to > > mention that. We usually don't document options that don't

  1   2   3   >