Hi,
On 7/29/19 10:25 AM, Alexander Korotkov wrote:
> * like_regex predicate uses our regular expression engine, which
> deviates from standard.
I still favor adding some element to the syntax (like a 'posix' or 'pg'
keyword in the grammar for like_regex) that identifies it as using
a different
On 07/29/19 18:27, Alexander Korotkov wrote:
> What do you think about renaming existing operator from like_regex to
> pg_like_regex? Or introducing special flag indicating that PostgreSQL
> regex engine is used ('p' for instance)?
Renaming the operator is simple and certainly solves the problem
On 8/2/19 10:32 AM, Karl O. Pinc wrote:
> But I'm not happy with putting any function that works with
> bytea into the binary string section. This would mean moving,
> say, length() out of the regular string section.
I'm not sure why. The bytea section already has an entry for its
length() funct
42403fc1a9 Mon Sep 17 00:00:00 2001
From: nobody
Date: Fri, 2 Aug 2019 22:47:10 -0400
Subject: [PATCH] Improve documentation about our XML functionality.
Add a section explaining how our XML features depart from current
versions of the SQL standard. Update and clarify the descriptions
o
On 7/30/19 2:54 PM, Jeff Davis wrote:
> Logs are important to diagnose problems or monitor operations, but logs
> can contain sensitive information which is often unnecessary for these
> purposes. Redacting the sensitive information would enable easier
> access and simpler integration with analysis
On 8/5/19 3:20 PM, Joshua D. Drake wrote:
> intro.sgml today. Patch attached.
Things I noticed quickly:
broken up in to categoriess/in to/into/
Unstructured data via JSON(or XML ?)
s/Partioniing/Partitioning/
Regards,
-Chap
On 08/07/19 04:48, Thomas Munro wrote:
> as "poetic" and "rare", and then says it was used by one specific
> Victorian poet. Perhaps I'll send them a pull request: it's now G. M.
> Hopkins and PostgreSQL?
It does seem counter, original, spare, strange.
Regards,
-Chap
On 08/07/19 11:39, Tom Lane wrote:
> Pavel Stehule writes:
>> I should to use a cache accessed via fn_extra. There will be stored data
>> about function parameters (types). If I understand correctly, these data
>> should be stable in query, and then recheck is not necessary. Is it true?
>
> I wou
On 8/8/19 9:29 AM, Yonatan Misgan wrote:
> From: Thomas Munro
>> Perl, Python etc. If I were you I think I'd experiment with a
>> prototype implementation using PL/Perl, PL/Python etc (a way to
As a bit of subtlety that might matter, the internal representation
in PostgreSQL, as in ISO 8601, ap
On 08/15/19 02:58, Yonatan Misgan wrote:
> From this source code how can I get only the year to convert my own
> calendar year. I need this because Ethiopian calendar is totally differ
> from GC in terms of day, month and year.
I find myself wondering whether getting only the year is sufficient
On 8/26/19 10:10 AM, ROS Didier wrote:
> Hi
>
> I would like to check that postgresql is compatible with TLS 1.2.
> what test could I do to check this compatibility?
Hi,
I just now pointed this command at our PG 9.5 server at $work:
openssl s_client -connect dbhost:5432 -starttls postgres
and
Hi,
I don't mean "overload objectSubId" in any ObjectAddress that PG code
would ever see. I am only thinking of a data structure of my own that
is ObjectAddress-like and has all three components available all the
time, and for an object that's a type, I would find it handy to stash
a typmod there,
On 09/02/19 00:29, Tom Lane wrote:
> If this is totally independent of ObjectAddress, why are you even
> asking? I assume that what you mean is you'd like these values to
> bleed into ObjectAddresses or vice versa.
Only that I'm working on a data structure of my own to cache my own
representatio
On 09/02/19 11:41, Tom Lane wrote:
> Hm, apparently we already do handle that in some way, because
> this works:
> ...
> Nonetheless, I'd be pretty hesitant to allow somebody to use
> objsubid with some entirely different meaning for types.
As long as it stays an internal detail of a caching schem
I'm not sure what the usual shape of 'consensus' or 'resolution' is in these
things,
but it seems to me that the branch of this email thread that leads here
(through the
message from Robert that I'm replying to) is the one that felt like it was
converging.
I thought it was converging on the ide
number of clients is
equal to the number of threads. Although each thread has its own generator
state, each client does not (if there is more than one per thread), and as
soon as real select() delays start happening in CSTATE_WAIT_RESULT, the
clients dealt out to a given thread may not be hitting tha
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
Initial review is the message this is in reply to.
The new status of
On 01/10/2018 11:08 AM, Robert Haas wrote:
> I think that we really need to think about allowing clients to tell
> the server which GUCs they'd like reported, instead of having a single
> list to which everyone is bound.
+1
That already sounded like a good idea back in
https://www.postgresql.org
On 01/10/2018 03:11 PM, Robert Haas wrote:
> it will only work on versions that support that option, but that is
> true of any new feature. Furthermore, they will easily be able to
> tell based on the reported server version whether or not their request
> for different behavior was accepted by th
I see there are some tests in src/test/regress:
sql/numeric.sql
expected/numeric.out
They pass. I see "numeric ... ok" in a make check.
I do not doubt they are being run, because if I edit numeric.sql
and fudge some digits, say around
-- cases that used to error out
select 0.12 ^ (-25);
select
On 01/11/18 02:07, Tom Lane wrote:
> Hm, it won't help your sanity to know that those cases pass fine
> for me, interactively, on a couple of different machines:
> ...
> You sure you're using a stock build of Postgres? No handmade
> versions of operator ^ lying around?
Interesting thought
A
On 01/11/2018 07:44 AM, Sergei Kornilov wrote:
> Hello
> I am surprised, but i can confirm error on versions prior 9.6: on 9.5, 9.4,
> 9.3 same error. On 9.6 and 10 query works correctly
One of my tests (in fact, the one where I first noticed) was a build
from git a couple days ago at e35dba475a4
On 01/11/2018 11:23 AM, Alvaro Herrera wrote:
> Dagfinn Ilmari Mannsåker wrote:
>> ilm...@ilmari.org (Dagfinn Ilmari Mannsåker) writes:
>>
>>> The behaviour seems to have changed in 9.6:
>>
>> Indeed, https://www.postgresql.org/docs/current/static/release-9-6.html
>> has the following entry:
>>
>>
On 01/11/18 11:30, Chapman Flack wrote:
> And indeed, my starting message in this thread was that, even in my
> recent (e35dba475a440f73dccf9ed1fd61e3abc6ee61db) build, make check
> *succeeds*, and for all I can tell, that test *is* executed (it shows
> up in the log, and if I re
On 01/13/18 21:36, Everaldo Canuto wrote:
> I don't wanna be irritating but here every postgres user I found really
> can't understand how the original patch was not accepted, people against it
> did not show good reasons.
As I was watching this thread go by, the reasons being shown seemed good
t
On 01/15/18 11:56, David Fetter wrote:
>> And while trying to find the EOF setting in libreadline might get
>> messy, you're already assuming that ctrl-C hasn't been knobbled
>> using stty intr. Unless you want to go searching for that too?
>
> I'm pretty sure changing either or both of those sett
On 01/15/18 16:32, David Fetter wrote:
> On Mon, Jan 15, 2018 at 01:24:45PM -0500, Chapman Flack wrote:
>> On 01/15/18 11:56, David Fetter wrote:
>>>> And while trying to find the EOF setting in libreadline might get
>>>> messy, you're already assuming that
On 01/17/18 06:50, Geoff Winkless wrote:
> Having said all that, has anyone suggested grabbing and writing out
> using the "stty quit" value? That appears to work whatever level
> you're at, readline-or-not, mid-line or not. It wasn't even something
> I was aware of.
Well, the usual use of SIGQUI
On 12/14/2006 01:17 PM, Peter Eisentraut wrote:
> Tom Lane wrote:
>> Peter Eisentraut writes:
>>> By extrapolation of the SQL standard, I'd say we'd need to check
>>> the EXECUTE privilege of the function at run time.
>>
>> Certainly EXECUTE privilege is what to check, but whose privilege?
>
> ..
Thanks! I had actually registered that one (with a related one)
for CF 2018-03, having missed the deadline for -01:
https://commitfest.postgresql.org/17/1467/
-Chap
On 01/24/2018 01:20 PM, Bruce Momjian wrote:
> On Thu, Dec 14, 2017 at 06:12:35PM -0500, Chapman Flack wrote:
>> On 12/0
On 01/29/18 03:32, Antonin Houska wrote:
> Robert Haas wrote:
>>> only take place if we had a special equality operator which distinguishes
>>> the
>>> *binary* values (I don't know yet how to store this operator the catalog ---
...
>> We don't have an operator that tests for binary equality, bu
On 01/29/2018 11:13 AM, Simon Riggs wrote:
> On 29 January 2018 at 15:44, Bruce Momjian wrote:
>> Uh, if we know we are going to get question on this, the patch had
>> better have an explanation of when to use it. Pushing the problem to
>> later doesn't seem helpful.
>
> What problem are you ref
On 02/01/2018 10:54 AM, Magnus Hagander wrote:
> in saying that git:// is faster than https://. In fact, we have some
> reports and testing that https:// can be significantly faster (due to other
> reasons).
Can you elaborate on the other reasons? It occurs to me that there
might be cases in which
CREATE FUNCTION commence_primary_ignition(target text, password text)
RETURNS void AS ...;
SELECT commence_primary_ignition(target=>'Alderaan', password=>'1234');
/* 1234 could appear in logs, activity stats ... disturbing */
CREATE OR REPLACE FUNCTION commence_primary_ignition(
target tex
On 02/02/18 22:46, Tom Lane wrote:
> ... the problem with this idea is that knowledge that the item ought to be
> hidden would be obtained only very late in the parsing process. So for
> example if you fat-fingered something just to the left of the function
> call in the query text, or the name o
Since commit aaf15e5, a text value doesn't reliably roundtrip through
representation as an XML attribute. At least, not like this:
WITH t(v) AS (SELECT text 'This & That'),
x(e) AS (SELECT xmlelement(name foo, xmlattributes(v)) FROM t),
y(v1) AS (SELECT (xpath('/foo/@v', e))[1]::text FROM x)
SELEC
On 11/05/19 18:54, Andres Freund wrote:
> Hi,
>
> There's a few errors that we issue that are, often, much less bad than
> they sound. The most common cases I immediately can recall are:
>
>
> 1) Mentioning crash, once for each backend, when shutting down
> immediately. Currently the log output
On 11/7/19 2:13 PM, Stephen Frost wrote:
>> That doesn't seem like a big objection from here. We could fix it
>> by making a separate privilege bit, but I doubt that it's worth using
>> up one of our limited set of spare bits for.
>
> I do not agree that we should just shift to using default rol
On 09/29/19 20:13, Chapman Flack wrote:
> 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
&
On 10/20/19 14:47, Tom Lane wrote:
> Chapman Flack writes:
>> 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 alignment, i.e., no alignment needed.
>&g
On 11/13/19 12:49 PM, David Fetter wrote:
>> Or just define %w as meaning "whitespace of the same width as
>> PROMPT1". You couldn't use it *in* PROMPT1, then, but I see
>> no use-case for that anyway.
>
> +1 for doing it this way. Would it make more sense to error out if
> somebody tried to set
On 12/29/19 02:30, Fabien COELHO wrote:
>>> C modulo operator (%) is a pain because it is not positive remainder
>>> (2 % -3 == -1 vs 2 % 3 == 2, AFAICR).
>>
>> This does not seem to be the case...
> ...
> Because I do not trust C modulo as I had a lot of problems with it? :-)
If I recall correct
On 1/3/20 1:46 PM, Robert Haas wrote:
> On Fri, Jan 3, 2020 at 1:10 PM Merlin Moncure wrote:
>> Just stop doing it. It's very little extra work to package an item
>> into an extension and this protects your hapless users who might have
>> implemented a function called gcd() that does something di
On 1/3/20 2:11 PM, Robert Haas wrote:
> and moving things to another schema does not help with that. It does
> potentially help with the namespace pollution issue, but how much of
> an issue is that anyway? Unless you've set up an unusual search_path
> configuration, your own schemas probably prece
On 1/3/20 3:09 PM, Peter Eisentraut wrote:
> Geometry is generally in scope, though, for Postgres specifically and
> for databases in general.
>
> Abstract algebra is not in scope, so far, and we still haven't been told
> the use case for this.
It's funny, I think I've used gcd and lcm in real li
On 1/3/20 4:10 PM, Alvaro Herrera wrote:
> Maybe a very simple solution is indeed to have a separate pg_math or
> pg_extra or whatever, which by default is *last* in the search_path.
> That would make a user's gcd() be chosen preferently, if one exists.
I'm liking the direction this is going.
Re
On 1/14/20 10:10 AM, Tom Lane wrote:
> to me that this error is just useless pedantry. As long as the DB
> encoding can represent the desired character, it should be transparent
> to users.
That's my position too.
Regards,
-Chap
On 1/14/20 4:25 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On Wed, Jan 15, 2020 at 4:25 AM Chapman Flack wrote:
>>> On 1/14/20 10:10 AM, Tom Lane wrote:
>>>> to me that this error is just useless pedantry. As long as the DB
>>>> encoding can rep
On 4/1/19 4:22 PM, Tom Lane wrote:
> Chapman Flack writes:
>> So, xml-functions-type-docfix-6.patch.
>
> Pushed with some light(?) copy-editing.
>
> I believe this closes out everything discussed in
>
> https://commitfest.postgresql.org/22/1872/
>
> but
On 04/01/19 17:34, Alvaro Herrera wrote:
> I think there were some outright bugs in the docs, at least for
> XMLTABLE, that maybe we should backpatch. If you have the energy to
> cherry-pick a minimal doc update to 10/11, I offer to back-patch it.
I'll see what I can do. There's breathing room fo
>> "Daniel Verite" writes:
>>> One consequence of using the "C" collation in the catalog versus
>>> the db collation
As an intrigued Person Following At Home, I was happy when I found
this little three-message thread had more context in [1] and [2]. :)
-Chap
[1] https://postgr.es/m/15938.154437
On 04/13/19 15:56, Tomas Vondra wrote:
> I think it might be useful to actually have that directly in the CF app,
> not just in the thread. There would need to a way to enter multiple
> hashes, because patches often have multiple pieces.
The CF app already recognizes (some) attachments in the emai
Hi,
Both tables in $subject (in datatype.sgml and xfunc.sgml, respectively)
contain similar information (though the xfunc one mentions C structs and
header files, and the datatype one does not, but has a description column)
and seem similarly out-of-date with respect to the currently supported
typ
On 4/29/19 2:45 PM, Peter Eisentraut wrote:
>> A policy issue, independent of this mechanism, is how many different
>> SQL spec versions we want to show in the table.
>
> We had previously established that we want to show 92 and the latest
> two. I don't propose to change that.
An annoying API r
On 5/16/19 12:24 PM, Albert Cervera i Areny wrote:
> Missatge de Thomas Munro del dia dj., 16 de
> maig 2019 a les 13:09:
>> With all three mitigations activated, my little dev machine has gone
>> from being able to do ~11.8 million baseline syscalls per second to
>
> Did you mean "1.8"?
Not in
On 05/31/19 16:04, Alvaro Herrera wrote:
> https://www.iso.org/standard/41528.html "XQuery Regular Expression
> Support in SQL"
Although I hadn't seen that particular document, I did see those in the
SQL spec and mention them in the wiki page [1].
I should point out that's also a conformance not
Hi,
We had a short conversation about this on Friday but I didn't have time
to think of a constructive suggestion, and now I've had more time to
think about it.
Regarding the proposed PG 13 jsonpath extensions (array, map, and
sequence constructors, lambdas, map/fold/reduce, user-defined
function
On 6/3/19 3:23 PM, Melanie Plageman wrote:
> Peter and I implemented this small (attached) patch to extend
> abbreviated key compare sort to macaddr8 datatype (currently supported
> for macaddr).
Am I going cross-eyed, or would the memset be serving more of a purpose
if it were in the SIZEOF_DATUM
On 6/3/19 5:03 PM, Chapman Flack wrote:
> On 6/3/19 3:23 PM, Melanie Plageman wrote:
>> Peter and I implemented this small (attached) patch to extend
>> abbreviated key compare sort to macaddr8 datatype (currently supported
>> for macaddr).
>
> Am I going cross-e
On 6/3/19 5:59 PM, Chapman Flack wrote:
> On 6/3/19 5:03 PM, Chapman Flack wrote:
> 1. (This one seems like a bug.) In the little-endian case, if
>SIZEOF_DATUM is smaller than the type, I'm not convinced by doing
>the DatumBigEndianToNative() after the memcpy(). Seems lik
On 10/12/2018 01:10 PM, Christoph Berg wrote:
> Re: Andres Freund 2018-10-12
> Andres' idea would enable the old code to continue to work, but
> couldn't we additionally to backpatch the ALLOCSET_*_SIZES macros, so
> the new code works also on old versions that didn't get the new
> AllocSetContext
On 10/23/18 13:15, Steve Crawford wrote:
> On Tue, Oct 23, 2018 at 10:08 AM Vaidyanathaswamy, Anandsaikrishnan <
> avaidyanathasw...@corelogic.com> wrote:
>> We are not able proceed with the installation manually. I am wondering
>> whether ubuntu 14 is compatible with version 8.3.7
...
> First, I
On 10/23/18 1:51 PM, Vaidyanathaswamy, Anandsaikrishnan wrote:
> configure: error: readline library not found
> If you have readline already installed, see config.log for details on the
> failure. It is possible the compiler isn't looking in the proper directory.
> Use --without-readline to disab
Inspired by the wiki page on PostgreSQL vs SQL Standard in general,
I have made another wiki page specifically about $subject. I hope
this was not presumptuous, and invite review / comment. I have not
linked to it from any other page yet.
https://wiki.postgresql.org/wiki/PostgreSQL_vs_SQL/XML_Stan
On 05/18/18 15:50, Robert Haas wrote:
> On Thu, May 17, 2018 at 9:37 AM, Stefan Fercot
> wrote:
>> ERROR: invalid XML content
>> DETAIL: line 1: StartTag: invalid element name
>> http://mrcc.com/qgis.dtd' 'SYSTEM'>
>> ^
>> CONTEXT: COPY layer_styles, line 1, column styleqml: "> 'http://mrcc.c
On 10/25/18 05:02, Tom Lane wrote:
> Chapman Flack writes:
>> a difference between the 2003 SQL/XML standard (which PG implements) and
>> the later versions, which changed the data model so there really is a
>> containment relationship between 'content
On 10/25/18 10:39 AM, Tom Lane wrote:
> I think getting out from under libxml2's idiosyncrasies and security
> lapses would be great, but is there a plausible alternative out there?
Depends on whether anything in [1] sounds plausible.
-Chap
[1]:
https://wiki.postgresql.org/wiki/PostgreSQL_vs_SQ
On 10/25/18 11:08 AM, Alvaro Herrera wrote:
> XQilla seems to depend on Xerces, and seems to have died in 2011.
¿Eh? The latest release, 2.3.4 [1], is dated 2018-07-03.
It looks like the latest development has been happening on the
xquilla_2_3 branch. Sometimes project "activity" statistics rely
On 10/25/18 11:15, Pavel Stehule wrote:
> čt 25. 10. 2018 v 17:09 odesílatel Alvaro Herrera
> napsal:
>> Maybe the best way forward is to implement all the JSON functionality
>> and remove the SQL/XML bits.
>
> It can be bigger compatibility break in Postgres history. SQL/XML functions
> are wide
On 10/25/18 09:56, Alvaro Herrera wrote:
> Would you review Markus Winand patch here?
> https://postgr.es/m/8bdb0627-2105-4564-aa76-7849f028b...@winand.at
> I think doing that would probably point out a couple of ways in which
> our XMLTABLE implementation is non-conformant, and then fixes it :-)
>
On 10/25/18 23:16, Pavel Stehule wrote:
>> XMLTABLE would be the headache. Using the standard name for something
>> that ain't the standard function has not left any painless way that the
>> standard function could be added. OTOH, it has only been in the wild
>> since 10, so renaming it to somethin
On 10/29/18 6:40 AM, Thomas Kellerer wrote:
> That line seems to be valid - but you need to pass an XMLTYPE value,
> not a VARCHAR
>
> https://dbfiddle.uk/?rdbms=oracle_11.2&fiddle=21cdf890a26e97fa8667b2d6a960bd33
Oh, of course! Thank you. I had forgotten pass the context item
as explicitly an XM
On 07/17/17 11:29, Michael Paquier wrote:
> On Thu, Jul 6, 2017 at 3:48 PM, Heikki Linnakangas wrote:
>> On 07/03/2017 06:30 PM, Chapman Flack wrote:
>>> Although it's moot in the straightforward approach of re-zeroing in
>>> the loop, it would still help my und
Back in
https://www.postgresql.org/message-id/4e384467-f28a-69ce-
75aa-4bc01125a39d%40anastigmatix.net
I got intrigued about casting float values to numeric. Two queries below
(one for float4, one for float8) show what happens for float values with
bits of precision from one up to the limit of th
es those
three failing for now.
-Chap
>From 5b3b05009830b29d1d3167bcd3321228535161dc Mon Sep 17 00:00:00 2001
From: Chapman Flack
Date: Sun, 25 Feb 2018 22:52:22 -0500
Subject: [PATCH 1/2] Add regression test for cast float[48] to numeric.
At this stage, as expected, it fails.
---
src/test/
On 02/26/2018 01:29 PM, Tom Lane wrote:
> I think there's probably a bigger chance of complaints that
> "casting 1.1::float8 to numeric now produces some weird,
> incorrectly-rounded result" than that we make anyone happier.
Arguably, though, that's a moment that can be used to explain
exactly wh
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
The patch 8 works and addresses the things I noticed earlier.
It
On 03/13/2018 10:40 AM, Stephen Frost wrote:
> * Michael Paquier (mich...@paquier.xyz) wrote:
>> Well, one thing is that the current checks in the postmaster make sure
>> that a data folder is never using anything else than 0700. From a
>> security point of view, making it possible to allow a post
On 03/13/2018 01:50 PM, Stephen Frost wrote:
> Yes, that's true, but PG has never paid attention to POSIX ACLs or Linux
> capabilities. Changing it to do so is quite a bit beyond the scope...
I think we're largely in agreement here, as my aim was not to advocate
that PG should work harder to und
uff that obstructs or tramples over what the admin takes care
to set up.
On 03/13/2018 03:44 PM, Stephen Frost wrote:
> * Chapman Flack (c...@anastigmatix.net) wrote:
>> So my suggestion boils down to PG having at least an option, somehow,
>> to be well-behaved in that sense.
>
On 03/15/2018 10:59 AM, Jeremy Finzel wrote:
> WaitLatch function the same variable worker_spi_naptime without referencing
> the configuration created in _PG_init. Am I missing something here?
You can see the declaration of that variable up on line 56.
It's just an int variable static to worker_
On 03/15/2018 04:19 PM, Jeremy Finzel wrote:
> Thank you. I did see worker_spi_naptime definition, but I wanted to
> pass worker_spi_naptime
> as an argument instead into worker_spi_main so that I can control via SQL
> interface how frequently the worker SQL executes. Is this possible?
Are you
I'm sorry, I must have missed your reply on the 5th somehow.
On 03/05/18 07:01, Fabien COELHO wrote:
> I must admit that I'm not too happy with the result as well, so I dropped
> the octal/hexadecimal parsing.
That seems perfectly reasonable to me; perfectly adequate to accept only
one base.
But
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: tested, failed
Spec compliant: not tested
Documentation:tested, failed
This is a simple patch, includes documentation, includes and pass
On 03/09/18 12:05, Emre Hasegeli wrote:
> In this case, I cannot see any other option than adding those as
> separate cast functions. Should we mark this entry as "returned with
> feedback"?
>
> We can also consider turning the current float to numeric casts to
> explicit as they are causing data
m both? I'll try attaching both to this one,
and see what it does.
This is good confirmation that the test is effective. :)
-Chap
From 35684bdaa1d27c3f4b7198541f3c92bb2b4cb2f4 Mon Sep 17 00:00:00 2001
From: Chapman Flack
Date: Sun, 25 Feb 2018 11:44:47 -0500
Subject: [PATCH] Zero headers of u
The SQL standard overloads WITH in a query to supply not only CTEs
but also lexically-scoped option settings:
WITH XMLBINARY BASE64, foo(bar) AS (VALUES('\xDEADBEEF'::bytea))
SELECT XMLELEMENT(name foo, XMLATTRIBUTES(bar)) FROM foo;
PG already implements XMLBINARY and XMLOPTION using the GUC sy
On 03/18/18 16:56, Daniel Gustafsson wrote:
> sorry about that. Now we know that the proposed test fails without the patch
> applied and clears with it, that was at least an interesting side effect =)
It was, and it got me looking at the test, and even though it does detect
the difference between
27;s enjoyment, coming right up.
-Chap
>From b2d36e3e4f4cd003cd7564a217bb15c19e1da5e2 Mon Sep 17 00:00:00 2001
From: Chapman Flack
Date: Sun, 18 Mar 2018 20:03:04 -0400
Subject: [PATCH] Add test for ensuring WAL segment is zeroed out
Switch to a new WAL file and ensure the last block in the
On 03/19/18 22:40, Tom Lane wrote:
> Craig Ringer writes:
>> Yes, looks like tests are necessary. I'd argue it's "test for broken Perl"
>> but apparently Fedora think they should split the Perl core dist into tiny
>> pieces.
>
> FWIW, the package boundaries are the same on RHEL6, and probably lon
list.
Regards,
Chapman Flack
Hi Rahul,
On 03/18/24 15:52, Rahul Uniyal wrote:
> Since the column format is text and not binary it converts the value
> to BigDecimal and give back the value as 40 .
> ...
> Now since the format is Binary ... it returns DOUBLE from there
> result in 40.0
>
> Now i am not sure for the same tabl
On 03/27/21 08:57, Andrew Dunstan wrote:
> We can bikeshed the name of the flag at some stage. --procedures-only
> might also make sense
Any takers for --routines-only ?
"Routine" is the genuine, ISO SQL umbrella term for a function or
procedure, and we have used it that way in our docs and gloss
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
v4 looks good to me.
I don't think this requires any documentation c
Adding this comment via the CF app so it isn't lost, while an
improperly-interpreted-DKIM-headers issue is still preventing me from mailing
directly to -hackers.
It was my view that the patch was getting close by the end of the last
commitfest, but still contained a bit of a logic wart made nec
On 2023-08-30 00:47, Andy Fan wrote:
see what it is. Suppose the original query is:
numeric(jsonb_object_field(v_jsonb, text)) -> numeric.
...
However the declared type of jsonb_object_field_type is:
jsonb_object_field_type(internal, jsonb, text) -> internal.
So the situation is: b). We retu
Hi,
On 2023-08-29 03:05, Jeevan Chalke wrote:
This commit implements jsonpath .bigint(), .integer(), and .number()
---
This commit implements jsonpath .date(), .time(), .time_tz(),
.timestamp(), .timestamp_tz() methods.
---
This commit implements jsonpath .boolean() and .string() methods.
Writ
On 2023-08-30 11:18, Chapman Flack wrote:
If I look in [1], am I looking in the right place for the most
current jsonpath draft?
My bad, I see that it is not. Um if I look in [1'], am I then looking
at the same spec you are?
[1'] https://www.ietf.org/archive/id/draft-ietf-jsonpa
On 2023-08-30 12:28, Alvaro Herrera wrote:
Yeah, I think the experience of the SQL committee with XML was pretty
bad, as you carefully documented. I hope they don't make such a mess
with JSON.
I guess the SQL committee was taken by surprise after basing something
on Infoset and XPath 1.0 for 2
On 2023-08-31 20:50, Vik Fearing wrote:
— An SQL/JSON item is defined recursively as any of the following:
...
• An SQL/JSON array, defined as an ordered list of zero or more
SQL/JSON items, called the SQL/JSON elements of the SQL/JSON
array.
...
— An SQL/JSON sequence is an o
201 - 300 of 624 matches
Mail list logo
