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 com

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: First draft of PG 17 release notes

Bruce Momjian wrote: > I 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 About the changes in collations: Create a "builtin" collation provider similar to libc's C locale (Jeff Davis

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: 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 server-

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 lc_collate.

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 reason

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 f

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é https://postgresql.verite.

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 to

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; c

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 tim

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 Com

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 mor

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: > > https://www.postgresql.org/message-id/flat/2019120606340

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 inter

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 sym

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 tha

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', dat

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 >ICU

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 default

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 "C.UTF-

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 LC_CTYPE=C,

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: 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 di

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 const-ne

Re: Built-in CTYPE provider

Noah Misch wrote: > If I'm counting the votes right, you and Tom have voted that the feature's > current state is okay, and I and Laurenz have voted that it's not okay. I > still hope more people will vote, to avoid dealing with the tie. Daniel, > Peter, and Jeremy, you're all listed as

Re: [18] Policy on IMMUTABLE functions and Unicode updates

Tom Lane wrote: > > I don't see how we can get by without some kind of versioning here. > > It's probably too late to do that for v17, > > Why? If we agree that that's the way forward, we could certainly > stick some collversion other than "1" into pg_c_utf8's pg_collation > entry. Ther

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

Sutou Kouhei wrote: > BTW, here is a diff after pgindent: PFA a v5 with the cosmetic changes applied. > I also confirmed that the updated server and non-updated > psql compatibility problem (the end-of-data "\." is > inserted). It seems that it's difficult to solve without > introducing

Re: Support LIKE with nondeterministic collations

Jeff Davis wrote: > > col LIKE 'smith%' collate "nd" > > > > is equivalent to: > > > > col >= 'smith' collate "nd" AND col < U&'smith\' collate "nd" > > That logic seems to assume something about the collation. If you have a > collation that orders strings by their sha256 hash,

Re: Opinion poll: Sending an automated email to a thread when it gets added to the commitfest

Jelte Fennema-Nio wrote: > I'd like to send an automatic mail to a thread whenever it gets added > to a commitfest Instead of sending a specific mail, what about automatically adding a mail header like: X-CommitFest-Entry: to every outgoing mail

Re: Multi-byte character case-folding

Tom Lane wrote: > CREATE TABLE public."myÉclass" ( >f1 text > ); > > If we start to case-fold É, then the only way to access this table will > be by double-quoting its name, which the application probably is not > expecting (else it would have double-quoted in the original CREATE TABL

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

Fabien COELHO wrote: > > I've also changed handleCopyOut() to return success if it > > could pump the data without writing it out locally for lack of > > an output stream. It seems to make more sense like that. > > I'm hesitating on this one. > > On the one hand the SQL query is executed

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

Fabien COELHO wrote: > sql> SELECT 1 \g /BAD > /BAD: Permission denied > > sql> \echo :ERROR > false That seems broken, because it's pointless to leave out a class of errors from ERROR. Presumably the purpose of ERROR is to enable error checking like: \if :ERROR ... error p

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

Fabien COELHO wrote: > (1) document ERROR as being muddy, i.e. there has been some error which > may be SQL or possibly client side. Although SQLSTATE would still allow to > know whether an SQL error occured, there is still no client side > expressions, and even if I had moved pgbench e

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

Fabien COELHO wrote: > > Now if you download data with SELECT or COPY and we can't even > > create the file, how is that a good idea to intentionally have the > > script fail to detect it? What purpose does it satisfy? > > It means that the client knows that the SQL command, and possible

Re: backslash-dot quoting in COPY CSV

Bruce Momjian wrote: > but I am able to see the failure using STDIN: > > COPY test FROM STDIN CSV; > Enter data to be copied followed by a newline. > End with a backslash and a period on a line by itself, or an EOF > signal. > "foo > \. > ER

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

Fabien COELHO wrote: > Sure. As there are several bugs (doubtful features) uncovered, a first > patch could fix "COPY ...TO STDOUT \g file", but probably replicate ERROR > current behavior however debatable it is (i.e. your patch without the > ERROR change, which is unrelated to the bug

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

Tom Lane wrote: > OK. I fixed the error-cleanup issue and pushed it. > > The patch applied cleanly back to 9.5, but the code for \g is a good > bit different in 9.4. I didn't have the interest to try to make the > patch work with that, so I just left 9.4 alone. Thanks! Now as far as I

Re: backslash-dot quoting in COPY CSV

Michael Paquier wrote: > In src/bin/psql/copy.c, handleCopyIn(): > > /* > * This code erroneously assumes '\.' on a line alone > * inside a quoted CSV string terminates the \copy. > * > http://www.postgresql.org/message-id/e1tdnvq-0001ju...@wrigleys.postgresql.org > */ > if (strcmp(buf, "

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

Tom Lane wrote: > A variant that might or might not be safer is "\g insist on you putting a mark there that shows you intended to read. > > Also, not quite clear what we'd do about copy-from-program. > I think "\g |foo" is definitely confusing for that. "\g foo|" > would be better if it

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

Tom Lane wrote: > > Now as far as I can see, there is nothing that \copy to file or program > > can do that COPY TO STDOUT cannot do. > > I don't think there's a way to get the effect of "\copy to pstdout" > (which, IIRC without any caffeine, means write to psql's stdout regardless > of w

Re: insensitive collations

Peter Eisentraut wrote: > Another patch. +ks key), in order for such such collations to act in a s/such such/such/ + +The pattern matching operators of all three kinds do not support +nondeterministic collations. If required, apply a different collation to +the expr

Re: backslash-dot quoting in COPY CSV

Bruce Momjian wrote: > > - the end of data could be expressed as a length (in number of lines > > for instance) instead of an in-data marker. > > > > - the end of data could be configurable, as in the MIME structure of > > multipart mail messages, where a part is ended by a "boundary", >

replace_text optimization (StringInfo to varlena)

Hi, replace_text() in varlena.c builds the result in a StringInfo buffer, and finishes by copying it into a freshly allocated varlena structure with cstring_to_text_with_len(), in the same memory context. It looks like that copy step could be avoided by preprending the varlena header to the Str

Re: Compressed TOAST Slicing

Paul Ramsey wrote: > Oddly enough, I couldn't find many/any things that were sensitive to > left-end decompression. The only exception is "LIKE this%" which > clearly would be helped, but unfortunately wouldn't be a quick > drop-in, but a rather major reorganization of the regex handling.

Re: Compressed TOAST Slicing

Paul Ramsey wrote: > > text_starts_with(arg1,arg2) in varlena.c does a full decompression > > of arg1 when it could limit itself to the length of the smaller arg2: > > Nice catch, I didn't find that one as it's not user visible, seems to > be only called in spgist (!!) It's also exposed

Re: [HACKERS] Can ICU be used for a database's default sort order?

Dmitry Dolgov wrote: > As a side note, I'm a bit confused, who is the original author of > the proposed patch? If it's Marina, why she isn't involved in the > discussion or even mentioned in the patch itself? The original patch [1] starts with these commit metadata: From e1cb130f550952

Re: Markdown format output for psql, design notes

Lætitia Avrot wrote: > But as Vik said earlier, maybe it's not worth it to provide a markdown > output as pandoc can generate the markdown from the HTML output. > And if you need the markdown output to generate HTML why don't you use the > HTML output ? The round-trip through pandoc does

Re: \gexec \watch

Alvaro Herrera wrote: > Honestly, I don't see the mathematicality in this. It either works, or > it doesn't -- and from my POV right now it doesn't. Are you saying we > need a \gexecwatch for this to work? > > I can of course solve my problem with a simple python program, but psql > is

Re: \gexec \watch

Alvaro Herrera wrote: > Hmm, thanks. AFAICS your hack reexecutes the initial query over and > over, instead of obtaining a fresh query each time. I see. That hack is about injecting something programmatically into the query buffer, but it seems you'd need to do that in a loop. And if psq

Re: [HACKERS] Can ICU be used for a database's default sort order?

Peter Eisentraut wrote: > Another issue is that we'd need to carefully divide up the role of the > "default" collation and the "default" provider. The default collation > is the collation defined for the database, the default provider means to > use the libc non-locale_t enabled API funct

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

I wrote: > I admit that if we could improve \g to handle COPY, it would be more > elegant than the current proposal adding two meta-commands. > > But the copy-workflow and non-copy-workflow are different, and in > order to know which one to start, \g would need to analyze the query It tu

Re: insensitive collations

Peter Eisentraut wrote: > So this doesn't actually make the collation case-insensitive or > anything, it just allows a library-provided collation that is, say, > case-insensitive to actually work that way. That's great news! > So maybe "insensitive" isn't the right name for this flag, bu

Re: insensitive collations

Tom Lane wrote: > I don't really find it "natural" for equality to consider obviously > distinct values to be equal. According to https://www.merriam-webster.com/dictionary/natural "natural" has no less than 15 meanings. The first in the list is "based on an inherent sense of right and

Changes to pg_dump/psql following collation "C" in the catalog

Hi, One consequence of using the "C" collation in the catalog versus the db collation is that pg_dump -t with a regexp may not find the same tables as before. It happens when these conditions are all met: - the collation of the database is not "C" - the regexp has locale-dependant parts - the nam

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

Fabien COELHO wrote: > Is this just kind of a bug fix? Beforehand the documentation says "\g fn" > sends to file, but that was not happening with COPY, and now it does as it > says? Yes. The doc says about \g: Sends the current query buffer to the server for execution. If an argume

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

Fabien COELHO wrote: > > It does not add "unless the query is a COPY", so it seems right > > to make that just work, and call it a bug fix. > > Does this suggest backpatching? Yes, I think it's a candidate for back-patching. > > There is a precedent in regress/sql/hs_standby_allowed.sql

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

Fabien COELHO wrote: > Dunno. Even if an additional tap test would not be backpatched, it could > be added on master. I'm basically sadden by pg test coverage, especially > psql which is under 40%, so I try to grasp any improvement opportunity… > > See https://coverage.postgresql.org/

backslash-dot quoting in COPY CSV

Hi, The doc on COPY CSV says about the backslash-dot sequence: To avoid any misinterpretation, a \. data value appearing as a lone entry on a line is automatically quoted on output, and on input, if quoted, is not interpreted as the end-of-data marker However this quoting does not happen

Re: insensitive collations

Peter Eisentraut wrote: > Here is an updated patch. When using GROUP BY and ORDER BY on a field with a non-deterministic collation, this pops out: CREATE COLLATION myfr (locale='fr-u-ks-level1', provider='icu', deterministic=false); =# select n from (values ('été' collate "myfr"), ('

Re: insensitive collations

Peter Eisentraut wrote: > > =# select n from (values ('été' collate "myfr"), ('ete')) x(n) > > group by 1 order by 1 ; > > n > > - > > ete > > (1 row) > > > > =# select n from (values ('été' collate "myfr"), ('ete')) x(n) > > group by 1 order by 1 desc; > > n > > - >

Re: insensitive collations

Peter Eisentraut wrote: > Here is an updated patch. On a table with pre-existing contents, the creation of a unique index does not seem to detect the duplicates that are equal per the collation and different binary-wise. postgres=# \d test3ci Table "public.test3ci" Colum

Re: insensitive collations

Andreas Karlsson wrote: > > Nondeterministic collations do address this by allowing canonically > > equivalent code point sequences to compare as equal. You still need a > > collation implementation that actually does compare them as equal; ICU > > does this, glibc does not AFAICT. > > A

Re: insensitive collations

Peter Eisentraut wrote: > > On a table with pre-existing contents, the creation of a unique index > > does not seem to detect the duplicates that are equal per the > > collation and different binary-wise. > > Fixed in the attached updated patch. Check. I've found another issue with aggre

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

Tom Lane wrote: > I took a quick look at this patch. PFA an updated patch addressing your comments and Fabien's. I've also changed handleCopyOut() to return success if it could pump the data without writing it out locally for lack of an output stream. It seems to make more sense like tha

Re: Making psql error out on output failures

David Zhang wrote: > > Are you sure? I don't find that redefinition. Besides > > print_aligned_text() also calls putc and puts. > Yes, below is the gdb debug message when psql first time detects the > error "No space left on device". Test case, "postgres=# select > repeat('111', 100)

Re: Unicode normalization SQL functions

Hi, I've checked the v3 patch against the results of the normalization done by ICU [1] on my test data again, and they're identical (as they were with v1; v2 had the bug discussed upthread, now fixed). Concerning execution speed, there's an excessive CPU usage when normalizing into NFC or NFKC.

Re: Unicode normalization SQL functions

One nitpick: Around this hunk: - * unicode_normalize_kc - Normalize a Unicode string to NFKC form. + * unicode_normalize - Normalize a Unicode string to the specified form. * * The input is a 0-terminated array of codepoints. * @@ -304,8 +306,10 @@ decompose_code(pg_wchar code, pg_wchar **

Re: Making psql error out on output failures

David Zhang wrote: > Thanks for your review, now the new patch with the error message in PG > style is attached. The current status of the patch is "Needs review" at https://commitfest.postgresql.org/27/2400/ If there's no more review to do, would you consider moving it to Ready for Co

RE: proposal: pg_restore --convert-to-text

José Arthur Benetasso Villanova wrote: > On Thu, 28 Feb 2019, Imai, Yoshikazu wrote: > > > Is there no need to rewrite the Description in the Doc to state we should > > specify either -d or -f option? > > (and also it might be better to write if -l option is given, neither -d nor > > -f

Re: Add parallelism and glibc dependent only options to reindexdb

Julien Rouhaud wrote: > > I think you'd be better off to define and document this as "reindex > > only collation-sensitive indexes", without any particular reference > > to a reason why somebody might want to do that. > > We should still document that indexes based on ICU would be exluded

Re: proposal: pg_restore --convert-to-text

Alvaro Herrera wrote: > So you suggest that it should be > > pg_restore: error: one of -d/--dbname, -f/--file and -l/--list must be > specified > ? I'd suggest this minimal fix : (int argc, char **argv) /* Complain if neither -f nor -d was specified (except if dumping TOC) */

Re: pg_stat_database update stats_reset only by pg_stat_reset

张连壮 wrote: > it reset statistics for a single table and update the column stats_reset of > pg_stat_database. > but i think that stats_reset shoud be database-level statistics, a single > table should not update the column stats_reset. This patch is a current CF entry at https://commitfest

Re: [PATCH] vacuumlo: print the number of large objects going to be removed

Timur Birsh wrote: > Please find attached patch v2. > I fixed some indentation in the variable declaration blocks. The tab width should be 4. Please have a look at https://www.postgresql.org/docs/current/source-format.html It also explains why opportunistic reformatting is futile, anyway:

Re: Stored procedures and out parameters

Vladimir Sitnikov wrote: > There's no notion if the called object is a procedure or function. > Note: PostgreSQL can have a function that `returns void`, and it is hard to > tell if {call test()} refers to a function or procedure. > > Can functions and procedures be unified at the backend

Re: Stored procedures and out parameters

David G. Johnston wrote: > > 2. A stored procedure can decide dynamically of > > the structure of the resultset(s) it returns, > > and the caller will discover it as they're returned, not > > before. > > > > The function itself doesn't care - this concern is about SELECT vs CALL > invocat

Doc patch: add RECURSIVE to bookindex

Hi, I've noticed that RECURSIVE as a term is not in the index, and thought it should be. PFA a patch to add it with references to WITH queries and CREATE VIEW. Best regards, -- Daniel Vérité PostgreSQL-powered mailer: http://www.manitou-mail.org Twitter: @DanielVerite diff --git a/doc/src/sgm

Re: Doc patch: add RECURSIVE to bookindex

Fabien COELHO wrote: > Why referencing only create_view, but not delete, insert, update, select > or select_into where RECURSIVE is also used? > > ISTM that at least the select page should be referenced, I'm less sure of > the others because there it appears only in the synopsys. Looki

Re: [HACKERS] Can ICU be used for a database's default sort order?

Andrey Borodin wrote: > Overall patch looks solid and thoughtful work and adds important > functionality. I tried the patch, with some minor changes to build with HEAD. I was surprised by the interface, that is, the fact that a user is not allowed to freely choose the ICU collation of a

Re: Allow COPY's 'text' format to output a header

Simon Muller wrote: > I've incorporated both your suggestions and included the patch you provided > in the attached patch. Hope it's as expected. Still unconvinced about the use case, since COPY's text format is only meant to be consumed by Postgres, and the only way that Postgres will consume

Re: Allow COPY's 'text' format to output a header

Simon Muller wrote: > I changed the error type and message for consistency with other similar > errors in that file. Whenever options are combined that are incompatible, > it looks like the convention is for a ERRCODE_SYNTAX_ERROR to be thrown. That makes sense, thanks for elaborating, al

Re: Stored procedures and out parameters

Shay Rojansky wrote: > In one way that's good, but I wonder how this squares with the following > written by David above: > > 1. A stored procedure should be able to return multiple resultsets with > different structures. > > 2. A stored procedure can decide dynamically of the structure of

Re: csv format for psql

Pavel Stehule wrote: > > On the whole I'm inclined to resubmit the patch with > > fieldsep_csv and some minor changes based on the rest > > of the discussion. > > > > +1 PFA an updated version. Usage from the command line: $ psql --csv # or -P format=csv $ psql --csv -P fieldsep

Rejecting redundant options in Create Collation

Hi, Currently, it's not an error for CREATE COLLATION to be invoked with options repeated several times. The last (rightmost) value is kept and the others are lost. For instance CREATE COLLATION x (lc_ctype='en_US.UTF8', lc_collate='en_US.UTF8', lc_ctype='C') silently ignores lc_ctype='en_US.UTF

Re: Rejecting redundant options in Create Collation

Michael Paquier wrote: > > Hmm ... I think that that is pretty standard behavior for a lot of > > our utility commands. Trying something at random, > > The behavior handling is a bit inconsistent. For example EXPLAIN and > VACUUM don't do that, because their parenthesized grammar got >

Re: speed up unicode decomposition and recomposition

John Naylor wrote: > I'd be curious how it compares to ICU now I've made another run of the test in [1] with your v2 patches from this thread against icu_ext built with ICU-67.1. The results show the times in milliseconds to process about 10 million short strings: operation | unpatched

Re: Add header support to text format and matching feature

Rémi Lapeyre wrote: > It looks like this is not in the current commitfest and that Cabot does not > find it. I’m not yet accustomed to the PostgreSQL workflow, should I just > create a new entry in the current commitfest? Yes. Because in the last CommitFest it was marked as "Returned with

Re: [RFC] Add an until-0 loop in psql

Corey Huinker wrote: > As of v11, DO blocks can do transactions. I think this will meet your needs. They do support COMMIT and ROLLBACK in the current development tree, but not VACUUM as in Pierre's example. postgres=# \echo :SERVER_VERSION_NAME 11devel postgres=# do ' begin vacuum; en

Re: Allow COPY's 'text' format to output a header

Andrew Dunstan wrote: > I'm not necessarily opposed to this, but I'm not certain about the use > case either. +1. The downside is that it would create the need, when using COPY TO, to know whether an input file was generated with or without header, and a hazard on mistakes. If you say it

Re: Allow COPY's 'text' format to output a header

Isaac Morland wrote: > Just to be clear, we're talking about my "header match" feature, not the > basic idea of allowing a header in text format? For my reply it was on merely allowing it, as does the current patch at https://commitfest.postgresql.org/18/1629 Best regards, -- Daniel Vér

Re: [HACKERS] SQL procedures

Tom Lane wrote: > Do we really want the existence of a function foo(int) to mean > that you can't create a SQL procedure named > foo and taking one int argument? Isn't it pretty much implied by the ALTER | DROP ROUTINE foo(...) commands where foo(...) may be either a procedure or a functi

Re: [HACKERS] Dynamic result sets from procedures

Peter Eisentraut wrote: > There is also one need error that needs further investigation. I've looked at this bit in the regression tests about \gexec: --- a/src/test/regress/expected/psql.out +++ b/src/test/regress/expected/psql.out @@ -232,11 +232,7 @@ union all select 'drop table gexe

Re: General purpose hashing func in pgbench

Fabien COELHO wrote: > Most "permutation" functions are really cryptographic cyphers which are > quite expensive, and require powers of two, which is not what is needed. > ISTM that there are some constructs to deal with arbitrary sizes based on > cryptographic functions, but that would

Re: csv format for psql

Fabien COELHO wrote: > Doc: "according to the csv rules" -> "according to csv rules."? Fixed. > Doc: "RFC-4180" -> "RFC 4180"? Fixed. The other references to RFCs use this syntax indeed. > The previous RFC specifies CRLF as eol, but '\n' is hardcoded in the > source. I'm fine with tha

Re: csv format for psql

Fabien COELHO wrote: > My point was more about the documentation which should be clear about what > is the EOL. I understand from your point above that the EOL is the > platform-specific one, which is yet again fine with me, but should be said > clearly in the documentation? Okay, I've

Re: transction_timestamp() inside of procedures

Tom Lane wrote: > I agree that it would be surprising for transaction timestamp to be newer > than statement timestamp. To me it's more surprising to start a new transaction and having transaction_timestamp() still pointing at the start of a previous transaction. This feels like a side-

Re: New "raw" COPY format

Joel Jacobson wrote: > However, I thinking rejecting such column data seems like the > better alternative, to ensure data exported with COPY TO > can always be imported back using COPY FROM, > for the same format. On the other hand, that might prevent cases where we want to export, for i

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

Joel Jacobson wrote: > - No Headers or Metadata: It's not clear why it's necessary to disable the HEADER option for this format? > The format does not support header rows or end-of-data markers; > every line is treated as data. With COPY FROM STDIN followed by inline data in a script,

Re: New "single" COPY format

Aleksander Alekseev wrote: > IMO it should be 'text' we already have with special options e.g. > DELIMITER AS NULL ESCAPE AS NULL. If there are no escape characters > and column delimiters (and no NULLs designations, and what else I > forgot) then your text file just contains one tuple per

<    1   2   3   4   >