Re: [HACKERS] Fwd: Have a problem with citext

On Oct 1, 2017, at 20:22, Robert Haas wrote: >> Are permissions correct in the citext extension? > > Not to be picky, but couldn't you investigate that a bit before posting here? Normally I would, but my attention is far from Postgres these days, sadly, and I tend to

[HACKERS] Fwd: Have a problem with citext

Hackers, Are permissions correct in the citext extension? Best, David > Begin forwarded message: > > From: Sadek Touati > Subject: Have a problem with citext > Date: September 29, 2017 at 17:02:50 EDT > To: "da...@kineticode.com" > > Dear

Re: [HACKERS] [BUGS] BUG #14825: enum type: unsafe use?

On Sep 25, 2017, at 10:55, Andrew Dunstan wrote: > Let's ask a couple of users who I think are or have been actually > hurting on this point. Christophe and David, any opinions? If I understand the issue correctly, I think I’d be fine with requiring ALTER TYPE

Re: [HACKERS] Malformed Array Literal in PL/pgSQL Exception Block

On Apr 9, 2017, at 9:59 PM, Andrew Gierth wrote: > Tom's response has the explanation of why it fails (everywhere, not just > in the exception block): parse analysis prefers to match the (array || > array) form of the operator when given input of (array || unknown).

Re: [HACKERS] Malformed Array Literal in PL/pgSQL Exception Block

On Apr 9, 2017, at 9:52 PM, Andrew Gierth wrote: > This "raise" statement is not reached, because the previous line raises > the "malformed array literal" error. Bah! > David> EXCEPTION WHEN OTHERS THEN > > If you change this to EXCEPTION WHEN

[HACKERS] Malformed Array Literal in PL/pgSQL Exception Block

Hackers, I’ve been happily using the array-to-element concatenation operator || to append a single value to an array, e.g, SELECT array || 'foo'; And it works great, including in PL/pgSQL functions, except in an exception block. When I run this: BEGIN; CREATE OR REPLACE

Re: [HACKERS] Fetch JSONB Value for UNIQUE Constraint

On Mar 24, 2017, at 5:00 PM, Peter Geoghegan wrote: >> So it’s a fine workaround, but maybe there’s something missing from the >> parsing of the CREATE TABLE statement? This is on 9.6.1. > > Unique constraints don't support expressions, or a predicate (partial-ness). Oh. Okay. I

[HACKERS] Fetch JSONB Value for UNIQUE Constraint

Dear Hackers, Should this work? CREATE TABLE things ( user_id INTEGER NOT NULL, document JSONB NOT NULL, UNIQUE (user_id, document->>'name') ); ERROR: syntax error at or near "->>" LINE 4: UNIQUE (user_id, document->>’name') I tried adding parens,

[HACKERS] Unacccented Fractions

Hello Hackers, I noticed that unaccent.rules has spaces in front of the unaccented representation of fraction glyphs: ¼1/4 ½1/2 ¾3/4 Note the space after the tab. In case my client kills what I’ve pasted, those lines match ¼\t[ ]1/4 ½\t[ ]1/2 ¾\t[ ]3/4 This makes

Re: [HACKERS] removing tsearch2

On Feb 27, 2017, at 1:53 PM, Bruce Momjian wrote: > Oh, does CPAN distribute compiled modules or requires users to compile > them. Like PGXN, it formally does not care, but its implementation expects source code distributions what will be built and installed by users. Note

Re: [HACKERS] removing tsearch2

On Feb 27, 2017, at 12:04 PM, Bruce Momjian wrote: > Just stating the obvious, but one of the reasons CPAN works so well is > that most of the modules are written in Perl and hence don't need > per-platform compilation. There are a *lot* of C-baded modules on CPAN; and my

Re: [HACKERS] removing tsearch2

On Feb 17, 2017, at 12:54 AM, Magnus Hagander wrote: > If we could somehow integrate PGXN with both the RPM build process, the DEB > build process and a Windows build process (whether driven by PGXN or just > "fed enough data" by PGXN is a different question), I think that

Re: [HACKERS] removing tsearch2

On Feb 14, 2017, at 9:37 AM, Magnus Hagander wrote: > It's a failing in one of the two at least. It either needs to be easier to > build the things on windows, or pgxn would need to learn to do binary > distributions. PGXN makes no effort to support installation on any

Re: [HACKERS] removing tsearch2

On Feb 14, 2017, at 5:37 AM, Jim Nasby wrote: >> Until pgxn has a way of helping users on for example Windows (or other >> platforms where they don't have a pgxs system and a compiler around), >> it's always going to be a "second class citizen". > > I view that as more

Re: [HACKERS] anyelement -> anyrange

On Aug 18, 2016, at 11:49 AM, Jim Nasby wrote: > Well crap, I searched for range stuff on PGXN before creating > http://pgxn.org/dist/range_tools/ and the only thing that came up was your > range_partitioning stuff, which AFAICT is unrelated. >

Re: [HACKERS] Add hint for function named "is"

On Aug 11, 2016, at 2:11 PM, Jim Nasby wrote: > CREATE FUNCTION pg_temp.is() RETURNS text LANGUAGE sql AS $$SELECT > 'x'::text$$; > SELECT 'x'||is(); > ERROR: syntax error at or near "(" > LINE 1: SELECT 'x'||is(); > > I was finally able to figure out this was

Re: [HACKERS] Does Type Have = Operator?

Sorry for the pgTAP off-topicness here, hackers. Please feel free to ignore. On May 17, 2016, at 8:10 AM, Jim Nasby wrote: > Speaking specifically to is(), what I'd find most useful is if it at least > hinted that there might be some type shenanigans going on, because

Re: [HACKERS] Does Type Have = Operator?

On May 17, 2016, at 7:58 AM, Jim Nasby wrote: > Probably in an attempt to bypass parse overhead on ingestion. > > Possibly because JSONB silently eats duplicated keys while JSON doesn't > (though in that case even casting to JSONB is probably not what you want). It’s

Re: [HACKERS] Does Type Have = Operator?

On May 12, 2016, at 12:02 PM, Tom Lane wrote: > Andrew mentions in the extension you pointed to that providing a default > comparison operator would enable people to do UNION, DISTINCT, etc on JSON > columns without thinking about it. I'm not convinced that "without >

Re: [HACKERS] Does Type Have = Operator?

On May 12, 2016, at 11:19 AM, Fabrízio de Royes Mello wrote: > Yeah.. it's ugly but you can do something like that: I could, but I won’t, since this is pgTAP and users of the library might have defined their own json operators. Andrew Dunstan has done the yeoman’s

Re: [HACKERS] Does Type Have = Operator?

On May 11, 2016, at 11:01 AM, Fabrízio de Royes Mello wrote: > I know... but you can do that just in case the current behaviour fail by > cathing it with "begin...exception...", so you'll minimize the looking for > process on catalog. Yeah, I guess. Honestly 90% of

Re: [HACKERS] Does Type Have = Operator?

On May 11, 2016, at 10:34 AM, Kevin Grittner wrote: > I'm not clear enough on your intended usage to know whether these > operators are a good fit, but they are sitting there waiting to be > used if they do fit. Huh. I haven’t had any problems with IS DISTINCT FROM for rows,

Re: [HACKERS] Does Type Have = Operator?

On May 11, 2016, at 10:19 AM, Kevin Grittner wrote: > As long as you don't assume too much about *what* is equal. > > test=# select '(1,1)(2,2)'::box = '(-4.5,1000)(-2.5,1000.5)'::box; > ?column? > -- > t > (1 row) Oh, well crap. Maybe I’d be better off just

Re: [HACKERS] Does Type Have = Operator?

On May 10, 2016, at 5:56 PM, Fabrízio de Royes Mello wrote: > Searching for the operator in pg_operator catalog isn't enought? Seems like overkill, but will do if there’s nothing else. Best, David smime.p7s Description: S/MIME cryptographic signature

Re: [HACKERS] Does Type Have = Operator?

On May 10, 2016, at 6:14 PM, Tom Lane wrote: > Given that you're coercing both one input value and the result to text, > I don't understand why you don't just compare the text representations. Because sometimes the text is not equal when the casted text is. Consider

[HACKERS] Does Type Have = Operator?

Hackers, pgTAP has a function that compares two values of a given type, which it uses for comparing column defaults. It looks like this: CREATE OR REPLACE FUNCTION _def_is( TEXT, TEXT, anyelement, TEXT ) RETURNS TEXT AS $$ DECLARE thing text; BEGIN IF $1 ~

Re: [HACKERS] Releasing in September

On Jan 20, 2016, at 9:42 AM, Joshua D. Drake wrote: > 4. Submit a patch, review a patch. > > Don't review patches? Don't submit patches. There will always be patches desirable-enough that they will be reviewed whether or not the submitter reviewed other patches. And

Re: [HACKERS] Very confusing installcheck behavior with PGXS

On Jan 7, 2016, at 11:20 AM, Jim Nasby wrote: >>> Also worth noting: the only reason I'm using pg_regress is it's the easiest >>> way to get a test cluster. If not for that, I'd just use pg_prove since I'm >>> already using pgTap. >> >> In 9.5 you might want to "use

[HACKERS] El Capitan Removes OpenSSL Headers

Hackers, Looks like Mac OS X 10.11 El Capitan has remove the OpenSSL header files. They recommend building your own or using native OS X SDKs, like Secure Transport: http://lists.apple.com/archives/macnetworkprog/2015/Jun/msg00025.html I don’t suppose anyone has looked at what it would take

Re: [HACKERS] OS X El Capitan and DYLD_LIBRARY_PATH

On Nov 4, 2015, at 8:37 PM, Michael Paquier wrote: > There is: > http://openradar.appspot.com/22807197 Yep, I filed that because I was unable to build the DBD::Oracle Perl module, since I can’t tell it where to find the SQL*Plus libraries. Big PITA. Apple says that

Re: [HACKERS] Patch to install config/missing

On Nov 2, 2015, at 1:07 PM, Tom Lane wrote: > I wonder how much we need that script at all though. If, say, configure > doesn't find bison, what's so wrong with just defining BISON=bison and > letting the usual shell "bison: command not found" error leak through? +1 This

Re: [HACKERS] [patch] extensions_path GUC

On Oct 23, 2015, at 9:26 AM, Jim Nasby wrote: > I would love it if make check worked. make installcheck adds extra effort to > extension develoopment, not to mention leaving your actual install in a less > than pristine state. I’ve wanted this for a long time. I

Re: [HACKERS] tsvector work with citext

On Sep 18, 2015, at 7:29 AM, Teodor Sigaev wrote: >> Fixable? > > Fixed (9acb9007de30b3daaa9efc16763c3bc6e3e0a92d), but didn't backpatch > because it isn't a critical bug. Great, thank you! For those on older versions, what’s the simplest workaround? Best, David --

Re: [HACKERS] tsvector work with citext

On Sep 17, 2015, at 6:17 AM, Teodor Sigaev wrote: > I'm wrong, in this commit it was just renamed. It was originally coded by me. > But it's still oversight. Fixable? Thanks, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to

[HACKERS] tsvector work with citext

Hey Hackers, Is there a way to get tsvector_update_trigger() to work with citext columns? The attached case throws an error: ERROR: column "title" is not of a character type Is the fact that citext is a (non-preferred) member of the string category not sufficient for this to work? If

Re: [HACKERS] Horizontal scalability/sharding

On Sep 1, 2015, at 1:47 PM, Robert Haas wrote: > Admittedly, there are some problems with snapshots here: if you don't > do anything special about snapshots, then what you have here will be > "eventually consistent" behavior. But that might be suitable for some >

Re: [HACKERS] pg_upgrade + Extensions

On Aug 31, 2015, at 4:20 PM, Bruce Momjian wrote: >> I think it would help if its noted somewhere in the document as it would have >> helped us save some time understanding why it was failing and why it was >> looking for json_build. > > The problem is that this is a rare

Re: [HACKERS] pg_upgrade + Extensions

On Aug 31, 2015, at 4:58 PM, Tom Lane wrote: > In any case, there is plenty of precedent for hard-coding knowledge about > specific version updates into pg_upgrade. The question here is whether > it's feasible to handle extensions that way. I think we could reasonably >

[HACKERS] pg_upgrade + Extensions

Hackers, My co-workers tell me that pg_upgrade told them to drop the colnames and hostname extensions before upgrading from 9.3 to 9.4. Fortunately, Postgres had not recorded any dependencies on functions from these extensions (not sure why not, since we do user them, but for the moment

Re: [HACKERS] pg_upgrade + Extensions

On Jul 10, 2015, at 11:32 AM, Smitha Pamujula smitha.pamuj...@iovation.com wrote: I just tested and yes that worked. Once we have the new library for the hostname, pg_upgrade is not complaining about the hostname extension. Great, thank you Smitha -- and Tom for the pointer. Your

Re: [HACKERS] creating extension including dependencies

On Jul 7, 2015, at 6:41 AM, Andres Freund and...@anarazel.de wrote: At the minimum I'd like to see that CREATE EXTENSION foo; would install install extension 'bar' if foo dependended on 'bar' if CASCADE is specified. Right now we always error out saying that the dependency on 'bar' is not

Re: [HACKERS] RFC: Remove contrib entirely

On Jun 5, 2015, at 12:34 AM, Jim Nasby jim.na...@bluetreble.com wrote: A number of modules also run Travis-CI. Might be worth having a way for a module to provide it's status .png. Right. Just stick it in your README. http://blog.pgxn.org/post/116087351668/badges David smime.p7s

Re: [HACKERS] Further issues with jsonb semantics, documentation

On Jun 4, 2015, at 12:16 PM, Alvaro Herrera alvhe...@2ndquadrant.com wrote: I'm just skimming here, but if a jsonb_path type is being proposed, Is this not the purpose of JSQuery? https://code.google.com/p/gwtquery/wiki/JsQuery David smime.p7s Description: S/MIME cryptographic signature

Re: [HACKERS] RFC: Remove contrib entirely

On Jun 4, 2015, at 11:53 AM, Neil Tiffin ne...@neiltiffin.com wrote: I have looked at PGXN and would never install anything from it. Why? Because it is impossible to tell, without inside knowledge or a lot of work, what is actively maintained and tested, and what is an abandoned

Re: [HACKERS] jsonb_set: update or upsert default?

On May 22, 2015, at 7:22 PM, Andrew Dunstan and...@dunslane.net wrote: The proposed flag for jsonb_set (the renamed jsonb_replace) in the patch I recently published is set to false, meaning that the default behaviour is to require all elements of the path including the last to be present.

Re: [HACKERS] Fixing busted citext function declarations

On May 11, 2015, at 5:01 PM, Tom Lane t...@sss.pgh.pa.us wrote: Me too. Something fell through the cracks rather badly there :-(. Would you check your commit history to see if anything else got missed? Let’s see… In

Re: [HACKERS] Fixing busted citext function declarations

Tom, On May 5, 2015, at 9:40 AM, Tom Lane t...@sss.pgh.pa.us wrote: In http://www.postgresql.org/message-id/bn1pr04mb37467aa1d412223b3d4a595df...@bn1pr04mb374.namprd04.prod.outlook.com it's revealed that the citext extension misdeclares its versions of regexp_matches(): they should return

Re: [HACKERS] Fixing busted citext function declarations

On May 5, 2015, at 10:07 AM, Alvaro Herrera alvhe...@2ndquadrant.com wrote: So AFAICS we need to actually drop and recreate the citext regexp_matches() functions in the upgrade script. That means ALTER EXTENSION citext UPDATE will fail if these functions are being used in any views. That's

Re: [HACKERS] Make more portable TAP tests of initdb

On Apr 14, 2015, at 9:05 AM, Alvaro Herrera alvhe...@2ndquadrant.com wrote: http://perldoc.perl.org/File/Path.html With this formulation: remove_tree($tempdir, {keep_root = 1}); Does Perl 5.8 have this? Yes, it does. http://cpansearch.perl.org/src/NWCLARK/perl-5.8.9/lib/File/Path.pm

Re: [HACKERS] Make more portable TAP tests of initdb

On Apr 14, 2015, at 1:21 PM, Alvaro Herrera alvhe...@2ndquadrant.com wrote: Castoroides has 5.8.4. Oops. WUT. smime.p7s Description: S/MIME cryptographic signature

Re: [HACKERS] Patch: Add launchd Support

On Mar 20, 2015, at 4:11 PM, David E. Wheeler da...@justatheory.com wrote: No one replied. Want a new patch with that? Here it is. Best, David launchd2.patch Description: Binary data smime.p7s Description: S/MIME cryptographic signature

Re: [HACKERS] Patch: Add launchd Support

On Mar 19, 2015, at 8:12 PM, Bruce Momjian br...@momjian.us wrote: Where are we on this? I suggested this plist: dict keyDisabled/key false/ keyLabel/key stringorg.postgresql.postgresql/string keyUserName/key stringpostgres/string

Re: [HACKERS] Patch: Add launchd Support

On Mar 20, 2015, at 4:21 PM, Jim Nasby jim.na...@bluetreble.com wrote: On 3/20/15 6:11 PM, David E. Wheeler wrote: keyProgramArguments/key array string/usr/local/pgsql/bin/postgres/string string-D/string string/usr/local/pgsql/data/string

Re: [HACKERS] using Core Foundation locale functions

On Nov 28, 2014, at 8:43 AM, Peter Eisentraut pete...@gmx.net wrote: At the moment, this is probably just an experiment that shows where refactoring and better abstractions might be suitable if we want to support multiple locale libraries. If we want to pursue ICU, I think this could be a

Re: [HACKERS] Trailing comma support in SELECT statements

On Oct 24, 2014, at 6:36 AM, Alex Goncharov alex.goncharov@gmail.com wrote: Another dimension of the trouble is breaking the operation of the tools that parse SQL statements for various purposes, e.g. for dependency analysis. That’s a valid point. This is a misfeature for the benefit

Re: [HACKERS] Trailing comma support in SELECT statements

On Oct 18, 2014, at 7:06 PM, Jim Nasby jim.na...@bluetreble.com wrote: Yes. The only case I can think of where we wouldn't want this is COPY. BTW, this should also apply to delimiters other than commas; for example, some geometry types use ; as a delimiter between points. I don’t think

[HACKERS] Patch: Add launchd Support

Hackers, In Mac OS X 10.10 “Yosemite,” Apple removed SystemStarter, upon which our OS X start script has relied since 2007. So here is a patch that adds support for its replacement, launchd. It includes 7 day log rotation like the old script did. The install script still prefers the

Re: [HACKERS] Patch: Add launchd Support

On Oct 20, 2014, at 4:36 PM, Tom Lane t...@sss.pgh.pa.us wrote: (1) I'd vote for just removing the SystemStarter stuff: it complicates understanding what's happening, to no very good end. We can easily check that the launchd way works back to whatever we think our oldest supported OS X

Re: [HACKERS] Patch: Add launchd Support

On Oct 20, 2014, at 4:58 PM, Jim Nasby jim.na...@bluetreble.com wrote: You're enabling POSTGRESQL in /etc/hostconfig before any of the files are copied over... what happens if we puke before the files get copied? Would it be better to enable after the scripts are in place? That code was

Re: [HACKERS] Patch: Add launchd Support

On Oct 20, 2014, at 5:17 PM, Tom Lane t...@sss.pgh.pa.us wrote: [ looks ... ] Yeah, there's no mention of KeepAlive in 10.4's launchd.plist man page. It does have a convenient example saying that OnDemand = false does what we want: Yeah, let’s see if we can cover both. I'd just drop them

Re: [HACKERS] Trailing comma support in SELECT statements

On Oct 17, 2014, at 3:18 PM, Tom Lane t...@sss.pgh.pa.us wrote: Yeah, exactly. Personally I'm *not* for this, but if we do it we should do it consistently: every comma-separated list in the SQL syntax should work the same. PL/pgSQL, too, I presume. D smime.p7s Description: S/MIME

Re: [HACKERS] json (b) and null fields

On Sep 29, 2014, at 9:09 AM, Tom Lane t...@sss.pgh.pa.us wrote: I seem to recall that we've run into practical difficulties with moving extensions into core. It might be OK for a functions-only extension though. It does make upgrading difficult, though, as I’ve learned the hard way with

Re: [HACKERS] jsonb format is pessimal for toast compression

On Sep 4, 2014, at 7:26 PM, Jan Wieck j...@wi3ck.info wrote: This is only because the input data was exact copies of the same strings over and over again. PGLZ can very well compress slightly less identical strings of varying lengths too. Not as well, but well enough. But I suspect such

Re: [HACKERS] Missing plpgsql.o Symbols on OS X

On Aug 27, 2014, at 9:53 PM, Ashesh Vashi ashesh.va...@enterprisedb.com wrote: Please add -arch x86_64 to your LD_FLAGS and CFLAGS in your make file. This made no difference: LDFLAGS = -arch x86_64 CFLAGS = -arch x86_64 Best, David signature.asc Description: Message signed with

Re: [HACKERS] Missing plpgsql.o Symbols on OS X

On Aug 27, 2014, at 4:20 PM, Tom Lane t...@sss.pgh.pa.us wrote: Yeah, but plpgsql.so is mentioned nowhere on your command line. I'm not too sure about the dynamic-linking rules on OS X, but I'd not be surprised if you need to provide a reference to plpgsql.so in its final installed location

[HACKERS] Missing plpgsql.o Symbols on OS X

Hackers, I’m trying to build Pavel’s plpgsql_check against the 9.4 beta on OS X 10.9, but get these errors: make gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv

Re: [HACKERS] Why is it JSQuery?

On Jun 15, 2014, at 1:58 PM, Josh Berkus j...@agliodbs.com wrote: In other words, what I'm saying is: I don't think there's an existing, poplular syntax we could reasonably use. Okay, I’m good with that. Would be handy to document it in such a way as to kind of put it forward as a standard.

Re: [HACKERS] make check For Extensions

On Jun 15, 2014, at 12:25 AM, Fabien COELHO coe...@cri.ensmp.fr wrote: I'm not sure the extension is sought for in the cluster (ie the database data directory). If you do make install the shared object is installed in some /usr/lib/postgresql/... directory (under unix), and it is loaded from

Re: [HACKERS] make check For Extensions

On Jun 12, 2014, at 11:40 PM, Fabien COELHO coe...@cri.ensmp.fr wrote: I would suggest to add that to https://wiki.postgresql.org/wiki/Todo. I may look into it when I have time, over the summer. The key point is that there is no need for a temporary installation, but only of a temporary

Re: [HACKERS] make check For Extensions

On Jun 12, 2014, at 11:28 AM, Fabien COELHO coe...@cri.ensmp.fr wrote: My 0.02€: It is expected to work, more or less, see the end of http://www.postgresql.org/docs/9.3/static/extend-pgxs.html That says: “The scripts listed in the REGRESS variable are used for regression testing of your

[HACKERS] make check For Extensions

Hackers, Andres said during the unconference last month that there was a way to get `make check` to work with PGXS. The idea is that it would initialize a temporary cluster, start it on an open port, install an extension, and run the extension's test suite. I think the pg_regress

Re: [HACKERS] Why is it JSQuery?

On Jun 6, 2014, at 3:50 PM, Josh Berkus j...@agliodbs.com wrote: Maybe we should call it jsonesque ;-) I propose JOQL: JSON Object Query Language. Best, David PS: JAQL sounds better, but [already exists](http://code.google.com/p/jaql/). signature.asc Description: Message signed with

Re: [HACKERS] Why is it JSQuery?

On Jun 10, 2014, at 12:06 PM, Oleg Bartunov obartu...@gmail.com wrote: we have many other tasks than guessing the language name. jsquery is just an extension, which we invent to test our indexing stuff. Eventually, it grew out. I think we'll think on better name if developers agree to have

Re: [HACKERS] Why is it JSQuery?

On Jun 6, 2014, at 6:54 AM, Oleg Bartunov obartu...@gmail.com wrote: Jsquery - is QUERY language, JsonPath - is language to EXTRACT json parts. Sure, but could we not potentially build on its syntax, instead of building a new one? I’m not saying we *should*, but if we don’t, I think there

Re: [HACKERS] Why is it JSQuery?

On Jun 6, 2014, at 12:51 PM, Josh Berkus j...@agliodbs.com wrote: * [JAQL](https://code.google.com/p/jaql/): Too different from SQL * [JSONPath](http://goessner.net/articles/JsonPath/): Too verbose I don't agree with the too verbose, but lacking AND|OR is pretty crippling. I had enough

[HACKERS] Why is it JSQuery?

Oleg, Teodor, and Hackers: Love what you’re doing with JSQuery. I’m curious, though, whether you considered adopting an existing syntax, such as JSONPath. http://goessner.net/articles/JsonPath/ Might be easier for people to pick up and use. Thoughts? Best, David signature.asc

Re: [HACKERS] Why is it JSQuery?

On Jun 5, 2014, at 5:25 PM, Andrew Dunstan and...@dunslane.net wrote: My understanding is that it's meant to be analogous to tsquery. At first glance, JsonPath doesn't seem to support AND and OR operators, which would make it rather less expressive than I gather JSQuery is meant to be.

Re: [HACKERS] [PATCH] Replacement for OSSP-UUID for Linux and BSD

On May 27, 2014, at 7:44 AM, Tom Lane t...@sss.pgh.pa.us wrote: In either case, the problem remains of exactly what to call the e2fsprogs-derived implementation. It does seem that people who are familiar with these libraries call it that, but I'm worried that such a name will confuse those

Re: [HACKERS] [PATCH] Replacement for OSSP-UUID for Linux and BSD

On May 26, 2014, at 6:07 PM, Tom Lane t...@sss.pgh.pa.us wrote: This means that if we want to give users control over which implementation gets selected, we actually need *three* configure switches. In the attached revision of Matteo's patch, I called them --with-ossp-uuid (the existing

Re: [HACKERS] [PATCH] Replacement for OSSP-UUID for Linux and BSD

On May 26, 2014, at 9:30 PM, Tom Lane t...@sss.pgh.pa.us wrote: How about --with-unix-uuid? Or --with-ext2-uuid? Meh. Unix certainly subsumes BSD, so that doesn't seem like a very useful distinction. I guess we could use ext2 but that would just confuse most people. --with-uuid? Which

Re: [HACKERS] jsonb inequality operators

On May 20, 2014, at 4:39 PM, Andrew Dunstan and...@dunslane.net wrote: I have just noticed as I am preparing my slides well ahead of time :-) that we haven't documented the inequality operators of jsonb. Is that deliberate or an oversight? That’s gotta be an oversight. The hash and btree

Re: [HACKERS] default opclass for jsonb (was Re: Call for GIST/GIN/SP-GIST opclass documentation)

On May 6, 2014, at 2:20 PM, Bruce Momjian br...@momjian.us wrote: Stuck on the naming question. I'd be willing to do the patch legwork if we had a consensus (or even a proposal) for what to rename the current jsonb_ops to. Well, then, we only have a few days to come up with a name. What

Re: [HACKERS] default opclass for jsonb (was Re: Call for GIST/GIN/SP-GIST opclass documentation)

On May 6, 2014, at 3:39 PM, Tom Lane t...@sss.pgh.pa.us wrote: Meh. I would not think that that represents effective use of JSON: if the rows are all the same, why aren't you exposing that structure as regular SQL columns? IMHO, the value of JSON fields within a SQL table is to deal with

Re: [HACKERS] psql blows up on BOM character sequence

On Mar 23, 2014, at 8:03, Guillaume Lelarge guilla...@lelarge.info wrote: Just a quick comment on this. Yes, pgAdmin always added a BOM in every SQL files it wrote. From http://stackoverflow.com/questions/2223882/whats-different-between-utf-8-and-utf-8-without-bom: According to the Unicode

Re: [HACKERS] psql blows up on BOM character sequence

On Mar 21, 2014, at 2:16 PM, Andrew Dunstan and...@dunslane.net wrote: Surely if it were really a major annoyance, someone would have sent code to fix it during the last 4 years and more since the above. I suspect it's a minor annoyance :-) But by all means add it to the TODO list if

Re: [HACKERS] jsonb and nested hstore

On Mar 6, 2014, at 1:51 AM, Peter Geoghegan p...@heroku.com wrote: It's true for perl. Syntax of hstore is close to hash/array syntax and it's easy serialize/deserialize hstore to/from perl. Syntax of hstore was inspired by perl. I understand that. There is a module on CPAN called

Re: [HACKERS] jsonb and nested hstore

On Mar 5, 2014, at 8:49 AM, Andrew Dunstan and...@dunslane.net wrote: I think that was my estimate, but Peter did offer to do it. He certainly asserted that the effort required would not be great. I'm all for taking up his offer. +1 to this. Can you and Peter collaborate somehow to get it

Re: [HACKERS] jsonb and nested hstore

On Feb 27, 2014, at 3:54 AM, Robert Haas robertmh...@gmail.com wrote: It's not very clear to me why we think it's a good idea to share the tree-ish representation between json and hstore. In deference to your comments that this has been very publicly discussed over quite a considerable

Re: [HACKERS] extension_control_path

On Feb 6, 2014, at 6:51 AM, Greg Stark st...@mit.edu wrote: Homebrew sounds kind of confused. Having a non-root user have access to make global system changes sounds like privilege escalation vulnerability by design. Well, the point is that it *doesn’t* make global system changes. I got an

Re: [HACKERS] extension_control_path

On Feb 6, 2014, at 7:32 AM, Stephen Frost sfr...@snowman.net wrote: The end-admin would have to modify the system-installed postgresql.conf anyway to enable this other directory. David wasn't suggesting that Homebrew *should* be able to do so, he was pointing out that it *can't*, which all

Re: [HACKERS] jsonb and nested hstore

On Feb 5, 2014, at 3:59 PM, Andrew Dunstan and...@dunslane.net wrote: I got a slightly earlier start ;-) For people wanting to play along, here's what this change looks like: https://github.com/feodor/postgres/commit/3fe899b3d7e8f806b14878da4a4e2331b0eb58e8 Man I love seeing all that read.

Re: [HACKERS] extension_control_path

On Feb 6, 2014, at 9:14 AM, Greg Stark st...@mit.edu wrote: Installing into /usr/local is a global system change. Only root should be able to do that and any user that can do that can easily acquire root privileges. I agree with you, but I don’t think the Homebrew folks do. Or at least their

Re: [HACKERS] extension_control_path

On Jan 30, 2014, at 10:06 AM, Sergey Muraviov sergey.k.murav...@gmail.com wrote: Now it looks fine for me. Just as another data point, I recently submitted pgTAP to the Homebrew project This is the build-from-source system for OS X, used by a lot of web developers. In my build script, I

Re: [HACKERS] nested hstore patch

On Jan 11, 2014, at 1:47 PM, Andrew Dunstan and...@dunslane.net wrote: It's been committed at https://github.com/feodor/postgres/commit/a21a4be55a5b12c4bd89b6ab2f77cf32e319de31. It will be in the next version of the patch posted. Bah! Sorry about that. Habit from decades of typing HTML.

Re: [HACKERS] nested hstore patch

On Nov 12, 2013, at 10:35 AM, Teodor Sigaev teo...@sigaev.ru wrote: Hi! Attatched patch adds nesting feature, types (string, boll and numeric values), arrays and scalar to hstore type. My apologies for not getting to this sooner, work has been a bit nutty. The truth is that I reviewed

Re: [HACKERS] Proposal: variant of regclass

On Dec 5, 2013, at 7:52 AM, Tom Lane t...@sss.pgh.pa.us wrote: BTW, another arguable advantage of fixing this via new functions is that users could write equivalent (though no doubt slower) functions for use in pre-9.4 releases, and thus not need to maintain multiple versions of app code that

Re: [HACKERS] Extension Templates S03E11

On Dec 3, 2013, at 9:14 AM, Dimitri Fontaine dimi...@2ndquadrant.fr wrote: I understand that it can happen, it still really sucks when it does. delusionnal paragraph, censored for lack of humour (incl. sarcasm) I have not followed this project closely, Dimitri, but I for one have

Re: [HACKERS] Extension Templates S03E11

On Dec 2, 2013, at 6:14 AM, Dimitri Fontaine dimi...@2ndquadrant.fr wrote: Whether you're targetting a file system template or a catalog template, PGXN is not a complete solution, you still need to build the extension. This is true today, but only because PostgreSQL provides the infrastructure

[HACKERS] Toward a Database URI Standard

Hackers, I've been toying with the idea of a standard for database URIs, mostly inspired by the libpq and JDBC formats Here's a writeup: http://theory.so/rfc/2013/11/26/toward-a-database-uri-standard/ What do you think? Thanks, David -- Sent via pgsql-hackers mailing list

Re: [HACKERS] nested hstore patch

On Nov 20, 2013, at 6:19 AM, Peter Eisentraut pete...@gmx.net wrote: openjade:hstore.sgml:206:16:E: document type does not allow element VARLISTENTRY here; assuming missing VARIABLELIST start-tag Thanks, I fixed this one. David -- Sent via pgsql-hackers mailing list

  1   2   3   4   5   6   7   8   9   10   >