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 think of citext (IT’S NOT

[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 sir, > I'm using the citext datatype in my applicati

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 ADD LABEL to be disallowed in a t

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). Just > cast the 'foo' to the a

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 division_by_zero THEN, the > reported error b

[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 FUNCTION

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 assumed the sy

[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 sens

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 that the vast majori

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 guess is that, more oft

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 would go a > long wa

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 platform at all. Happy

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 of a failing of pgxs than

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. > http://pgxn.org/dist/range_type_functions/still d

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 because "is" needs to be quoted;

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 I've run > across somethi

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 also when you’d want text

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 > thinking about it" is a goo

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 work of creating such opera

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 this issue would go away fo

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, except for the situ

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 comparing the plain text of

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 'foo'::citext = 'FOO':ci

[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 there will often be patche

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 PostgresNode" which allows yo

[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 t

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 the more people file bugs, t

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 would certainly make it

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 think it would have to create a

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 -- Sent via pgsql-hacker

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 your subscription:

[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 not,

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 > environments, such as very loose

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 > expect to know about cas

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 case where you had an

Re: [HACKERS] pg_upgrade + Extensions

On Jul 10, 2015, at 11:32 AM, Smitha Pamujula 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 installation references loadable l

[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 gratef

Re: [HACKERS] creating extension including dependencies

On Jul 7, 2015, at 6:41 AM, Andres Freund 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 fullfilled - not p

Re: [HACKERS] RFC: Remove contrib entirely

On Jun 5, 2015, at 10:47 AM, Jim Nasby wrote: >> Right. Just stick it in your README. >> >> http://blog.pgxn.org/post/116087351668/badges > > I meant something more integrated with PGXN itself, such as what you're > proposing for pgxn-tester. That would allow for things like PGXN search > r

Re: [HACKERS] RFC: Remove contrib entirely

On Jun 5, 2015, at 12:34 AM, Jim Nasby 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 Description: S/MIME cryptogra

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

On Jun 4, 2015, at 12:16 PM, Alvaro Herrera 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 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 > proof-of-concept or idea.

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

On May 22, 2015, at 7:22 PM, Andrew Dunstan 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. What that > does i

Re: [HACKERS] Fixing busted citext function declarations

On May 11, 2015, at 5:01 PM, Tom Lane 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 https://github.com/theory/citext/commit/4030b4e1ad9fd9f994a6cdca1126a903682acae4 I copied y

Re: [HACKERS] Fixing busted citext function declarations

Tom, On May 5, 2015, at 9:40 AM, Tom Lane 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 SETOF text[] but

Re: [HACKERS] Fixing busted citext function declarations

On May 5, 2015, at 10:07 AM, Alvaro Herrera 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 annoying but I

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

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

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

On Apr 14, 2015, at 9:05 AM, Alvaro Herrera 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 Best, David smim

Re: [HACKERS] Patch: Add launchd Support

On Mar 20, 2015, at 4:11 PM, David E. Wheeler 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 20, 2015, at 4:21 PM, Jim Nasby wrote: > > On 3/20/15 6:11 PM, David E. Wheeler wrote: >> ProgramArguments >> >> /usr/local/pgsql/bin/postgres >> -D >> /usr/local/pgsql/data >> > > Hrm

Re: [HACKERS] Patch: Add launchd Support

On Mar 19, 2015, at 8:12 PM, Bruce Momjian wrote: > Where are we on this? I suggested this plist: Disabled Label org.postgresql.postgresql UserName postgres GroupName postgres ProgramArguments /us

Re: [HACKERS] using Core Foundation locale functions

On Nov 28, 2014, at 8:43 AM, Peter Eisentraut 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 useful third

Re: [HACKERS] Trailing comma support in SELECT statements

On Oct 24, 2014, at 6:36 AM, Alex Goncharov 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 of edit-lazy users only.

Re: [HACKERS] Patch: Add launchd Support

On Oct 20, 2014, at 5:17 PM, Tom Lane 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 into files in t

Re: [HACKERS] Patch: Add launchd Support

On Oct 20, 2014, at 4:58 PM, Jim Nasby 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 there; I just indented it

Re: [HACKERS] Patch: Add launchd Support

On Oct 20, 2014, at 4:36 PM, Tom Lane 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 release is. (10.4.x

[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 SystemStart

Re: [HACKERS] Trailing comma support in SELECT statements

On Oct 18, 2014, at 7:06 PM, Jim Nasby 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 it should apply to

Re: [HACKERS] Trailing comma support in SELECT statements

On Oct 17, 2014, at 3:18 PM, Tom Lane 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 cryptographic signature

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

On Sep 29, 2014, at 9:09 AM, Tom Lane 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 when upgrading from

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

On Sep 4, 2014, at 7:26 PM, Jan Wieck 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 > input data wou

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

On Aug 27, 2014, at 4:20 PM, Tom Lane 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 (ie, a refere

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

On Aug 27, 2014, at 9:53 PM, Ashesh Vashi 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 OpenPGP using GPGMail

[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 -I/usr/lo

Re: [HACKERS] Why is it "JSQuery"?

On Jun 15, 2014, at 1:58 PM, Josh Berkus 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. :-) D signatu

Re: [HACKERS] make check For Extensions

On Jun 15, 2014, at 12:25 AM, Fabien COELHO 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 there, > but

Re: [HACKERS] make check For Extensions

On Jun 12, 2014, at 11:40 PM, Fabien COELHO 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 > cluster, and to

Re: [HACKERS] make check For Extensions

On Jun 12, 2014, at 11:28 AM, Fabien COELHO 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 module, which can b

Re: [HACKERS] Why is it "JSQuery"?

On Jun 10, 2014, at 12:06 PM, Oleg Bartunov 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 it in core. For

Re: [HACKERS] Why is it "JSQuery"?

On Jun 6, 2014, at 3:50 PM, Josh Berkus 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 OpenPGP using GPGMai

[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 --temp-install

Re: [HACKERS] Why is it "JSQuery"?

On Jun 6, 2014, at 12:51 PM, Josh Berkus 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 people complain

Re: [HACKERS] Why is it "JSQuery"?

On Jun 6, 2014, at 6:54 AM, Oleg Bartunov 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 should be a discussio

Re: [HACKERS] Why is it "JSQuery"?

On Jun 5, 2014, at 5:25 PM, Andrew Dunstan 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. Yes, but perhaps it

[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 Description:

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

On May 27, 2014, at 7:44 AM, Tom Lane 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 not so familiar.

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

On May 26, 2014, at 9:30 PM, Tom Lane 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 one is

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

On May 26, 2014, at 6:07 PM, Tom Lane 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 switch name), --wit

Re: [HACKERS] jsonb inequality operators

On May 20, 2014, at 4:39 PM, Andrew Dunstan 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 index support is do

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 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 data that is not

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 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 are the op

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

On Mar 23, 2014, at 8:03, Guillaume Lelarge 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 standard, the BOM fo

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

On Mar 21, 2014, at 2:16 PM, Andrew Dunstan 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 it's not there al

Re: [HACKERS] jsonb and nested hstore

On Mar 6, 2014, at 1:51 AM, Peter Geoghegan 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 Pg::hstore that >

Re: [HACKERS] jsonb and nested hstore

On Mar 5, 2014, at 8:49 AM, Andrew Dunstan 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 knocked out? > In

Re: [HACKERS] jsonb and nested hstore

On Feb 27, 2014, at 3:54 AM, Robert Haas 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 period, I went back and

Re: [HACKERS] extension_control_path

On Feb 6, 2014, at 9:14 AM, Greg Stark 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 current im

Re: [HACKERS] jsonb and nested hstore

On Feb 5, 2014, at 3:59 PM, Andrew Dunstan wrote: > I got a slightly earlier start ;-) For people wanting to play along, here's > what this change looks like: > Man I love seeing all that read. :-) D -- S

Re: [HACKERS] extension_control_path

On Feb 6, 2014, at 7:32 AM, Stephen Frost 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 makes sense imv.

Re: [HACKERS] extension_control_path

On Feb 6, 2014, at 6:51 AM, Greg Stark 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 error on OS

Re: [HACKERS] extension_control_path

On Jan 30, 2014, at 10:06 AM, Sergey Muraviov 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 originally had depends_on :

Re: [HACKERS] nested hstore patch

On Jan 11, 2014, at 1:47 PM, Andrew Dunstan wrote: > It's been committed at > . > It will be in the next version of the patch posted. Bah! Sorry about that. Habit from decades of typing HTML. David -- Sent

Re: [HACKERS] nested hstore patch

On Nov 12, 2013, at 10:35 AM, Teodor Sigaev 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 this patch quite

Re: [HACKERS] Proposal: variant of regclass

On Dec 5, 2013, at 7:52 AM, Tom Lane 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 relies on this

Re: [HACKERS] Extension Templates S03E11

On Dec 3, 2013, at 9:14 AM, Dimitri Fontaine wrote: > I understand that it can happen, it still really sucks when it does. > > I have not followed this project closely, Dimitri, but I for one have appreciated your tenacity in following through on it. Extensions are awesome, thanks to you, a

Re: [HACKERS] Extension Templates S03E11

On Dec 2, 2013, at 6:14 AM, Dimitri Fontaine 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 for building and in

[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 (pgsql-hackers

  1   2   3   4   5   6   7   8   9   10   >