On 11/23/21 10:41, Isaac Morland wrote:
> Umm, it's definitely negative:
>
> odyssey=> select '1 month -31 days +12:00:00'::interval < '0
> months'::interval;
> --
> t
Well, what you've shown here is that it's "negative" according to
an arbitrary total ordering imposed in interval_cmp_va
Hi,
By inspection of plperl and plpython, it looks like the canonical pattern
for a PL using internal subtransactions is:
save CurrentMemoryContext
save CurrentResourceOwner
BeginInternalSubTransaction
reimpose the saved memory context
// but not the saved resource owner
...
(RollbackAnd)?Releas
On 11/29/21 16:31, Daniel Gustafsson wrote:
> That's a good point, the hint is targeting users who might not even know that
> an extension needs to be physically and separately installed on the machine
> before it can be installed in their database; so maybe using "installed" here
> isn't entirely
On 11/29/21 17:03, Tom Lane wrote:
> I think "The extension must ..." would read better, otherwise +1.
I'm not strongly invested either way, but I'll see if I can get at why
I used 'an' ...
Hints are hinty. We can give them, and they're helpful, because there
are certain situations that we know a
On 11/29/21 17:13, Bossart, Nathan wrote:
> postgres=# CREATE EXTENSION does_not_exist;
> ERROR: extension "does_not_exist" is not available
> DETAIL: The extension must first be installed on the system where
> PostgreSQL is running.
> HINT: The pg_available_exte
On 11/29/21 17:54, Bossart, Nathan wrote:
> postgres=# CREATE EXTENSION does_not_exist;
> ERROR: extension "does_not_exist" is not available
> DETAIL: Extension control file
> "/usr/local/pgsql/share/extension/does_not_exist.control" does not exist.
> HINT: The
Hi,
Can somebody confirm or correct what I (think I)'ve gleaned from
the code?
- Commit timestamps are always WAL logged, and so in principle
determinable after the fact (with some amount of effort), regardless
of the track_commit_timestamp setting. (I guess this must have long
been true, t
On 03/25/18 23:27, Stephen Frost wrote:
>> .travis.yml | 47
>>
>
> ... not something that I think we're going to add into the main tree.
Looks like that got in by mistake, sorry.
> - AdvanceXLInsertBuffer(CurrPos
gt; page's header is short not long.
Here are patches responding to that (and also fixing the unintended
inclusion of .travis.yml).
What I have not done here is respond to Michael's objection, which
I haven't had time to think more about yet.
-Chap
>From 3606cccfd584654970f56e909798d0d1
On 03/26/18 01:43, Michael Paquier wrote:
> Have a look at BKP_REMOVABLE then. This was moved to page headers in
> 2dd9322, still it seems to me that the small benefits outlined on this
> thread don't justify breaking tools relying on this flag set, especially
> if there is no replacement for it.
On 03/27/18 20:09, Tomas Vondra wrote:
> Not sure what's up with gitweb, but git finds it without any issue:
>
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=2dd9322ba6eea76800b38bfea0599fbc459458f2
Thanks, that worked.
On 03/27/18 22:10, Michael Paquier wrote:
> Here you go fo
On 03/30/18 16:21, Tom Lane wrote:
> Yup. Pushed with some rewriting of the comments.
Thanks!
> I did not like the proposed test case too much, particularly not its
> undocumented API change for check_pg_config,
Other than that API change, was there something the test case could have
done diff
On 03/30/18 19:57, Michael Paquier wrote:
> look for tools using XLP_BKP_REMOVABLE. One is pglesslog that we
> already know about. However I have to be honest, I have not been able
> to find its source code,
I'm glad it wasn't just me.
-Chap
Hi,
If I copy an out-of-line, on-disk TOAST pointer into a memory context
with transaction lifetime, with an eye to detoasting it later in the
same transaction, are there circumstances where it wouldn't work?
Thanks,
-Chap
On 04/01/18 01:19, Tom Lane wrote:
> Chapman Flack writes:
>> If I copy an out-of-line, on-disk TOAST pointer into a memory context
>> with transaction lifetime, with an eye to detoasting it later in the
>> same transaction, are there circumstances where it wouldn't wor
Hasn't been updated as built-in support grew for temp files, DSM segments,
and JIT contexts.
With enough luck, a README update won't break anything.
-Chap
>From fb06e17916ad6b445b1cf6361de6a7f2749ea225 Mon Sep 17 00:00:00 2001
From: Chapman Flack
Date: Fri, 6 Apr 2018 19:41:57
On 04/06/18 19:52, Andres Freund wrote:
> On 2018-04-06 19:46:25 -0400, Chapman Flack wrote:
>> Hasn't been updated as built-in support grew for temp files, DSM segments,
>> and JIT contexts.
>>
>> With enough luck, a README update won't break anything.
>
On 04/06/18 20:19, Chapman Flack wrote:
> On 04/06/18 19:52, Andres Freund wrote:
>> Wouldn't it be a better idea not to have a list there, that's guaranteed
>> to get out of date?
>
> That might look like this, then.
>
> But I'm not sure ho
On 04/08/2018 02:01 AM, Andrew Gierth wrote:
> Chapman> (d) some other reason I haven't thought of ?
>
> It has to be pushed as the active snapshot so that it's the snapshot
> that the executor uses to run the query to populate the tuplestore which
> becomes the "held" portal content.
That seem
On 04/10/18 00:30, Andrew Gierth wrote:
> That's not precisely true - ultimately, the routines that do actual
> scans take the snapshot to use as a parameter, and the executor mostly
> references the snapshot from the EState; but a bunch of places do
> require that ActiveSnapshot be set to the cur
On 04/10/2018 10:06 AM, Tom Lane wrote:
> Chapman Flack writes:
>> Am I right in thinking that, for my original purpose of
>> detoasting something later in a transaction, all that matters
>> is that I registered a snapshot from the time at which I copied
>> the toas
On 04/10/2018 04:03 PM, Robert Haas wrote:
> I suspect you want, or maybe need, to use the same snapshot as the
> scan that retrieved the tuple containing the toasted datum.
I'm sure it's worth more than that, but I don't know if it's
implementable.
If I'm a function, and the datum came to me as
On 04/10/2018 05:04 PM, Chapman Flack wrote:
> If I'm a function, and ... I found [the datum] myself, say by an
> SPI query within the function, usually that's at a level of abstraction
> somewhere above what-snapshot-was-used-in-the-scan.
It looks like for that case (since t
On 04/10/2018 05:04 PM, Chapman Flack wrote:
> ... I wonder if
> there's at least a cheap way to check a particular snapshot
> for suitability wrt a given toast pointer. Check a couple usual
> suspects, find one most of the time, fall back to eager detoasting
> otherwise?
>
On 04/10/2018 10:17 PM, Jan Wieck wrote:
> If your session has a transaction snapshot that protects the old toast
> slices from being vacuumed away, you are fine.
That harks back to my earlier (naïve?) thought that, as long as
my lazy datum doesn't have to outlive the transaction, lazy
detoasting
On 04/11/2018 10:41 AM, Tom Lane wrote:
> The core of the problem now is that in a READ COMMITTED transaction, we
> may not be holding any snapshot at all between statements. So if you're
> hanging onto a toast pointer across statements you're at risk.
>
> On the other hand, it's also arguable th
On 04/11/2018 11:33 AM, Tom Lane wrote:
> Chapman Flack writes:
>> The mission is to implement java.sql.SQLXML, which has long been
>> missing from PL/Java.
>> This is the class of object your Java code can retrieve from a
>> ResultSet row from a query with an XML colu
On 04/11/2018 01:55 PM, Tom Lane wrote:
> Chapman Flack writes:
>> Well, the devilsAdvocate() function would stash the object
>> in a static, then try to look at it some time in a later call
>> in the same transaction.
>
> If you're worried about that, you shou
On 04/11/2018 03:04 PM, Tom Lane wrote:
> Chapman Flack writes:
>> that it might *not* be sufficient to find an applicable snapshot at
>> the time of constructing the object, and register that snapshot
>> on TopTransactionResourceOwner?
>
> The problem is to know which
On 04/18/2018 12:27 PM, Simon Riggs wrote:
> Please change the name of the "JIT" parameter to something meaningful
> to humans before this gets too far into the wild.
>
> SSL is somewhat understandable because its not a Postgres-private term.
JIT is hardly a Postgres-private term. It's a familia
On 04/20/2018 09:55 AM, Matthias Kurz wrote:
> SET READONLY my_app.some_var = 'foo';
> SET READONLY SESSION my_app.some_var = 'foo';
> SET READONLY LOCAL my_app.some_var = 'foo';
>
> Of course read-only would default to false for backwards compatibility.
> When setting READONLY for on SESSION con
On 04/20/2018 04:03 PM, Andrew Gierth wrote:
>>>>>> "Chapman" == Chapman Flack writes:
> Chapman> It seemed to me at the time to be not hard to implement, even
> Chapman> just as an extension for proof of concept. One small obstacle
> Chapman> is
Hi Alvaro,
On 08/03/19 12:15, Alvaro Herrera wrote:
>> I don't know if it's too late to get in the upcoming minor releases,
>> but maybe it can, if it looks ok, or the next ones, if that's too rushed.
>
> Hmm, I'm travelling back home from a conference the weekend, so yeah I
> think it would be
On 09/16/19 17:10, Tom Lane wrote:
> I was initially troubled
> by the fact that XML Schema regexps are implicitly anchored, ie must
> match the whole string; that's a huge difference from POSIX. However,
> 19075-6 says that jsonpath like_regex works the same as the LIKE_REGEX
> predicate in SQL;
On 09/17/19 21:13, Jonathan S. Katz wrote:
> to), which describes being able to use "&#[0-9]+;" and "&#[0-9a-fA-F]+;"
Er, that is, "&#[0-9]+;" and "&#x[0-9a-fA-F]+;" (with x for the hex case).
>> Does
>> it work outside bracket expressions, or only inside?
>
> Looking at the parse tree (start
On 9/18/19 11:10 AM, Nikita Glukhov wrote:
> 4. Even if the Unicode escape sequence '\u' is used, it cannot produce
> special symbols or whitespace, because the identifiers are displayed
> ...
> I don't know if it is possible to check Unicode properties "ID_Start" and
> "ID_Continue" in Pos
On 09/18/19 17:12, Tom Lane wrote:
> After further reading, it seems like what that text is talking about
> is not actually a regex feature, but an outgrowth of the fact that
> the regex pattern is being expressed as a string literal in a language
> for which XML character entities are a native as
On 09/19/19 18:35, Tom Lane wrote:
> There remains the question of whether we should do something like
> requiring a "pg" prefix to allow access to the other nonstandard
> features we added to jsonpath. I see the point that the SQL committee
> might well add something pretty similar in future. B
On 9/20/19 9:46 AM, Robert Haas wrote:
> least, I think you do. There's probably some way to create a callback
> structure that lets you presuppose that the toplevel data structure is
> an array (or object) and get back each element of that array (or
> key/value pair) as it's parsed,
If a JSON pa
>From looking around the code, I've made these tentative observations
about TupleDescs:
1. If the TupleDesc was obtained straight from the relcache for some
relation, then all of its attributes should have nonzero attrelid
identifying that relation, but in (every? nearly every?) other case,
Hi,
The documentation for CREATE TYPE has this to say about alignment:
"The alignment parameter specifies the storage alignment required for the
data type. The allowed values equate to alignment on 1, 2, 4, or 8 byte
boundaries."
... while the documentation for pg_type has:
"c = char alignm
On 10/2/19 2:53 PM, Tom Mercha wrote:
> However, I'm not quite so sure how I can query over the
> EphemeralNamedRelation using SQL? Could someone indicate where I can
> find an example?
You could look in the documentation for CREATE TRIGGER in PG 10
or later, specifically the clauses like REFER
On 10/4/19 1:44 PM, Ashwin Agrawal wrote:
> macro exist in first place will be hard to remember. So, irrespective
> in long run, {0} might get used in code and hence seems better
> to just use {0} from start itself instead of macro/wrapper on top.
>
> Plus, even if someone starts out with thought
On 10/11/19 4:30 PM, Robert Haas wrote:
> But, if it does need to be changed, it seems like a terrible idea to
> allow it to be done via SQL. Otherwise, the user can break the driver
> by using SQL to set the list to something that the driver's not
> expecting, and there's nothing the driver can d
On 10/11/19 4:44 PM, Dave Cramer wrote:
> On Fri, 11 Oct 2019 at 16:41, Chapman Flack
>> On 10/11/19 4:30 PM, Robert Haas wrote:
>>> allow it to be done via SQL. Otherwise, the user can break the driver
>>> by using SQL to set the list to something that the driv
On 10/18/19 08:18, Stephen Frost wrote:
> I realize that I need to don some fireproof gear for suggesting this,
> but I really wonder how much fallout we'd have from just allowing {} to
> be used.. It's about a billion[1] times cleaner and more sensible than
> using {0} and doesn't create a depend
On 10/21/19 11:25 AM, Joe Nelson wrote:
> we have the
> INIT_ALL_ELEMS_ZERO macro to avoid (2). However the more I look at the
> code using that macro the less I like it. The {0} initializer is more
> idiomatic.
If faced with the two questions:
1. which of a or b is more "clear" ?
2. which of a o
On 2/28/19 9:52 AM, Dean Rasheed wrote:
> Does self-censoring mean that they might still throw an error for some
> inputs, but that error won't reveal any information about the input
> values? That's not entirely consistent with my understanding of the
> definition of leakproof
That's the questio
On 2/28/19 11:03 AM, Joshua Brindle wrote:
> How is leakproof defined WRT Postgres? Generally speaking a 1 bit
>From the CREATE FUNCTION reference page:
LEAKPROOF indicates that the function has no side effects. It reveals no
information about its arguments other than by its return value. For
ex
Hi, thanks for checking the patches!
On 02/28/19 19:36, Ramanarayana wrote:
> The below statement needs to be executed before running the query to
> replicate the issue
>
> update xmldata set data = regexp_replace(data::text, '791',
> '791')::xml;
If you are applying that update (and there is a
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:tested, passed
For completeness, I'll mark this reviewed again. It passes instal
On 03/01/19 07:15, Ramanarayana wrote:
> Hi,
> I have tested bug fixes provided by all the patches. They are working
> great. I found one minor issue
>
> select * from xmltable('*' PASSING 'pre arg?>&deeppost' COLUMNS x XML PATH '/');
>
> The above query returns the xml. But there is an extra pl
On 3/1/19 1:04 PM, David G. Johnston wrote:
> 1/0 is an illegal operation. We could return NaN for it but the choice of
> throwing an error is just as correct. Returning infinity is strictly
> incorrect.
That differs from my understanding of how the operations are specified
in IEEE 754 (as summ
On 3/1/19 2:26 PM, David G. Johnston wrote:
> Upon further reading you are correct - IEEE 754 has chosen to treat n/0
> differently for n=0 and n<>0 cases. I'm sure they have their reasons but
> ... I don't use,
> or have time for the distraction, to understand why such a decision was
> made and
On 3/1/19 3:49 PM, Matt Pulver wrote:
> In many applications, I would much rather see calculations carried out
> via IEEE 754 all the way to the end, with nans and infs, which
> provides much more useful diagnostic information than an exception that
> doesn't return any rows at all. As Andres Freu
On 03/01/19 17:34, Tom Lane wrote:
> but I think it'd be fragile to use. (See the "Type Conversion"
> chapter in the manual for the gory details, and note that domains
> get smashed to their base types mighty readily.)
>
> Using custom operator names would work better/more reliably.
Or a new ba
On 3/6/19 10:12 AM, Andrew Dunstan wrote:
> Having reviewed the thread, I'm with Andres and Tom. Maybe though we
> should have a note somewhere to the effect that you can't use VARIADIC
> with these.
Perhaps such a note belongs hoisted into the functions-conditional
section of the manual, making
This CF entry shows Pavel and me as reviewers, but the included
patches were also produced by one or the other of us, so additional
review by someone who isn't us seems appropriate. :)
Would it make sense to remove one or both of us from the 'reviewers'
field in the app, to make it more obviously
On 3/7/19 10:08 AM, Alvaro Herrera wrote:
> I just pushed this one to pg12 only:
>> xmltable-xmlexists-passing-mechanisms-3.patch
Thanks!
> I removed the words "first appears in SQL:2006" from the new doc
> paragraph; we used to have similar phrases scattered here and there but
> were removed ye
On 02/15/19 11:31, Peter Eisentraut wrote:
>> On 25/01/2019 15:37, Chapman Flack wrote:
>>> If they are already processed that way, does that mean the
>>>
>>> o Do not use text with so the URL appears in printed output
>>>
>>> in README.links s
Alvaro has committed two of the patches in this CF entry[1], but the
remaining two have yet to attract review.
This message contains only those two, just as before[2] except rebased
over Alvaro's commits of the others.
There are two new changes. The s added in the -docfix patch now
have link t
On 3/8/19 7:38 AM, Peter Eisentraut wrote:
> On 2019-03-08 05:04, Chapman Flack wrote:
>> -o If you want to supply text, use , else
>> +o If you want to supply text, use or , else
>
> The choice of vs is for internal links. For external
> links you have to use
On 03/11/19 19:53, Euler Taveira wrote:
> Em seg, 11 de mar de 2019 às 10:36, Andy Fan
> escreveu:
>>
>> I need some function which requires some message exchange among different
>> back-ends （connections).
>> specially I need a shared hash map and a message queue.
>>
> It seems you are looking
Hello hackers,
What exactly is a savepointLevel?
They seem to have been there for 15 years[1], diligently copied from
parent transactions to children, fastidiously checked to avoid crossing
a level on rollback or release, but does anything ever change the level
from its initial value? I'm drawing
On 3/15/19 11:46 AM, Pavel Stehule wrote:
> pá 15. 3. 2019 v 15:03 odesílatel David Fetter napsal:
>> Whatever optimizations you have in mind for this, could they also work
>> for string_to_array() and array_to_string() when they get an empty
>> string handed to them?
>
> my idea is use string_to
On 3/15/19 12:15 PM, Tom Lane wrote:
> Chapman Flack writes:
>> So the proposal seems roughly equivalent to making string_to_array's
>> second parameter optional default null, and array_to_string's second
>> parameter optional default ''.
>
> In t
On 3/15/19 12:26 PM, Pavel Stehule wrote:
> you use string_to_array function without separator, then only one possible
> semantic is there - separation by chars.
Other languages can and do specify other semantics for the
separator-omitted case: often (as in Python) it means to split
around "runs o
On 3/15/19 12:59 PM, Pavel Stehule wrote:
> for this proposal "char" != byte
>
> result[n] = substring(str FROM n FOR 1)
I think that's what string_to_array(..., null) already does:
SHOW server_encoding;
server_encoding
UTF8
WITH
t0(s) AS (SELECT text 'verlorn ist daz slüzzelîn'),
t1(a) AS (S
On 1/25/16 12:52 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sat, Jan 23, 2016 at 11:27 PM, Chapman Flack
>> wrote:
>>> What I would have expected would be to allow s
>>> for any Unicode codepoint that's representable in the server encoding,
>>>
Hi,
PL/Java implements JDBC Savepoints using BeginInternalSubTransaction/
ReleaseCurrentSubTransaction/RollbackAndReleaseCurrentSubTransaction.
That seems to be the Accepted Way of Doing Things within backend PLs
that want control over error recovery, am I right?
PL/Java also strictly enforces t
and also needs to be
reviewed.)
Further conversation should probably be on that email thread so that it
stays associated with the commitfest entry.
Thanks for your interest in the issue!
Regards,
Chapman Flack
[1] https://commitfest.postgresql.org/22/1872/
[2] https://www.postgresql.org/messag
On 03/16/19 16:42, Tom Lane wrote:
> Ryan Lambert writes:
>> I'm investigating the issue I reported here:
>> https://www.postgresql.org/message-id/flat/153478795159.1302.9617586466368699403%40wrigleys.postgresql.org
>> I'd like to work on a patch to address this issue and make it work as
>> advert
On 03/16/19 16:55, Tom Lane wrote:
> What do you think of the idea I just posted about parsing off the DOCTYPE
> thing for ourselves, and not letting libxml see it?
The principled way of doing that would be to pre-parse to find a DOCTYPE,
and if there is one, leave it there and parse the input as
On 03/16/19 17:21, Tom Lane wrote:
> Chapman Flack writes:
>> On 03/16/19 16:55, Tom Lane wrote:
>>> What do you think of the idea I just posted about parsing off the DOCTYPE
>>> thing for ourselves, and not letting libxml see it?
>
>> The principled way of
On 03/16/19 18:33, Chapman Flack wrote:
> The pre-scan is a simple linear search and will ordinarily say yes or no
> within a couple dozen characters--you could *have* an input with 20k of
> leading whitespace and comments, but it's hardly the norm. Just trying to
If the av
On 03/17/19 11:45, Tom Lane wrote:
> Chapman Flack writes:
>> On 03/16/19 17:21, Tom Lane wrote:
>>> (1) always try to parse as document. If successful, we're done.
>>> (2) otherwise, if allowed by xmloption, try to parse using our
>
>> What I don'
On 03/17/19 13:16, Tom Lane wrote:
> Chapman Flack writes:
>> What I was doing in the patch is the reverse: parsing with the expectation
>> of CONTENT to see if a DTD gets tripped over. It isn't allowed for an
>> element to precede a DTD, so that approach can be expec
On 03/17/19 15:06, Tom Lane wrote:
> The error message issue is indeed a concern, but I don't see why it's
> complicated if you agree that
>
>> If the query asked for CONTENT, any error result should be one you could get
>> when parsing as CONTENT.
>
> That just requires us to save the first erro
Hi,
Given a Portal, or an _SPI_plan, is there a practical way to tell whether
it came from a query with FOR UPDATE or FOR SHARE?
Regards,
-Chap
There might be too many different email threads on this with patches,
but in case it went under the radar, xml-content-2006-3.patch appeared
in my previous message on this thread[1].
It is based on a simple pre-check of the prefix of the input, determining
which form of parse to apply. That may or
On 03/18/19 22:38, Eric Hanson wrote:
> rows are really second class citizens: They aren't tracked with
> pg_catalog.pg_depend, they aren't deleted when the extension is dropped,
> etc.
This. You have other interests as well, but this is the one I was thinking
about a few years ago in [1] (starti
On 03/19/19 00:56, Chapman Flack wrote:
> Nobody ever chimed in to say how numerous they did or didn't think the
> problems would be. I was actually thinking recently about sitting down
> and trying to write that patch, as no one had exactly stood up to say
> "oh heavens no,
On 03/18/19 00:45, Tom Lane wrote:
> I think it would help to take two steps back and ask why you want
> to know this, and what exactly is it that you want to know, anyhow.
> What does it matter if there's FOR SHARE in the query? Does it
I was looking at an old design decision in PL/Java, which i
On 03/23/19 16:59, Tom Lane wrote:
> Unicode-code-point numbers. I removed that, made some other changes to
> bring the patch more in line with PG coding style, and pushed it.
Thanks! It looks good. I'm content with the extra PI checking being gone.
The magic Unicode-code-point numbers come stra
On 03/23/19 17:05, Tom Lane wrote:
> Just to update this thread --- per the other thread at
> https://postgr.es/m/can-v+g-6jquqeqz55q3toxen6d5ez5uvzl4vr+8ktvjkj31...@mail.gmail.com
> I've now pushed a somewhat-adjusted version of the XML-content fix
> patch. The documentation patch needs some sma
On 03/23/19 18:22, Tom Lane wrote:
>> Out of curiosity, what further processing would you expect libxml to do?
>
> Hm, I'd have thought it'd try to parse the arguments to some extent,
> but maybe not. Does everybody reimplement attribute parsing for
> themselves when using PIs?
Yeah, the content
On 03/23/19 18:20, Chapman Flack wrote:
>> Perhaps it'd make sense under the XML section in datatype.sgml,
>> but I think I might lean to making it a new section in Appendix D
>> (SQL Conformance).
>
> Sounds like the option (4) I proposed back in [1]. I suppose it wo
On 03/23/19 18:20, Chapman Flack wrote:
> On 03/23/19 17:05, Tom Lane wrote:
>> I've now pushed a somewhat-adjusted version of the XML-content fix
>> patch. The documentation patch needs some small rebasing to apply
>> after that one instead of before it.
>
>
On 03/24/19 21:04, Ryan Lambert wrote:
> I am unable to get latest patches I found [1] to apply cleanly to current
> branches. It's possible I missed the latest patches so if I'm using the
> wrong ones please let me know. I tried against master, 11.2 stable and the
> 11.2 tag with similar results
On 03/25/19 18:03, Ryan Lambert wrote:
> The following review has been posted through the commitfest application:
> make installcheck-world: tested, passed
> Implements feature: tested, passed
> Spec compliant: not tested
> Documentation:not tested
Hi,
Thanks for the
On 03/26/19 21:39, Ryan Lambert wrote:
> The following review has been posted through the commitfest application:
> make installcheck-world: tested, passed
> Implements feature: tested, passed
> Spec compliant: not tested
> Documentation:tested, passed
Thanks for the r
On 03/26/19 21:39, Ryan Lambert wrote:
> I can't verify technical accuracy for many of the details (nuances between
> XPath 1.0, et. al), but overall my experience with the XML functionality
> lines up with what has been documented here.
By the way, in case it's buried too far back in the email t
On 3/27/19 2:40 AM, Eric Hanson wrote:
> What would be the implications of adding a NO RESET clause to SET LOCAL
> ROLE?
There's a part of this that seems to be a special case of the
GUC-protected-by-cookie idea discussed a bit in [1] and [2]
(which is still an idea that I like).
Regards,
-Chap
On 3/27/19 9:31 AM, Alvaro Herrera wrote:
> Everyone calls it "libxml2" nowadays. Let's just use that and avoid any
> possible confusion. If some libxml3 emerges one day, it's quite likely
> we'll need to revise much more than our docs in order to use it.
That's persuasive to me. I'll change the
Hi,
xml-functions-type-docfix-5.patch attached, with node-sets instead of
nodesets, libxml2 instead of libxml, and parenthesized full sentences
now au naturel.
I ended up turning the formerly-parenthesized note about libxml2's
node-set ordering into a DocBook : there is really something
parenthet
On 03/27/19 19:07, Chapman Flack wrote:
> xml-functions-type-docfix-5.patch attached, with node-sets instead of
> nodesets, libxml2 instead of libxml, and parenthesized full sentences
> now au naturel.
>
> I ended up turning the formerly-parenthesized note about libxml2's
>
On 03/28/19 17:56, Peter Geoghegan wrote:
> SQLite has a bubble generator tool that they use to generate syntax
> diagrams for their documentation:
>
> https://www.sqlite.org/docsrc/doc/tip/art/syntax/bubble-generator.tcl?mimetype=text/plain
>
> I think that the results are rather good. See, for
On 03/27/19 19:27, Chapman Flack wrote:
> A column marked FOR ORDINALITY will be populated with row numbers
> matching the order in which the output rows appeared in the original
> input XML document.
>
> I've been skimming right over it all this time, and that right
On 3/29/19 3:32 PM, Joe Conway wrote:
> pg_util
>
> Of course that does not lend itself to symlinking for backward
> compatibility, does it? If there is a way I am not familiar with it.
On Unix-like systems, you can have pg_util look at argv[0] to see
if it was called createuser or what not.
On 07/24/19 03:45, John Naylor wrote:
> On Sun, Jul 21, 2019 at 3:14 AM Tom Lane wrote:
>> However, my second reaction was that maybe you were on to something
>> upthread when you speculated about postponing de-escaping of
>> Unicode literals into the grammar. If we did it like that then
Wow, ya
101 - 200 of 624 matches
Mail list logo
