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

[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

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

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

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

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

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

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

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

[HACKERS] PL/pgSQL PERFORM with CTE

Hackers, This seems reasonable: david=# DO $$ david$# BEGIN david$# WITH now AS (SELECT now()) david$# SELECT * from now; david$# END; david$# $$; ERROR: query has no destination for result data HINT: If you want to discard the results of a SELECT, use PE

Re: [HACKERS] PL/pgSQL PERFORM with CTE

Hi Pavel, On Aug 20, 2013, at 2:11 PM, Pavel Stehule wrote: >> david=# DO $$ >> david$# BEGIN >> david$# WITH now AS (SELECT now()) >> david$# PERFORM * from now; >> david$# END; >> david$# $$; >> ERROR: syntax error at or near "PERFORM" >> LINE 4: PE

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On Aug 20, 2013, at 2:24 PM, Marko Tiikkaja wrote: >> postgres=# DO $$ >> BEGIN >>PERFORM * FROM (WITH now AS (SELECT now()) >> SELECT * from now) x; >> END; >> $$; >> DO > > .. which doesn't work if you want to use table-modifying CTEs. Which, in fact, is exactly my use case (though no

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On Aug 20, 2013, at 2:31 PM, Pavel Stehule wrote: > but it works > > postgres=# do $$begin with x as (select 10) insert into omega select * from > x; end;$$; > DO But this does not: david=# DO $$ david$# BEGIN david$# PERFORM * FROM ( david$# WITH inserted AS ( david$#

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On Aug 20, 2013, at 2:41 PM, Pavel Stehule wrote: > yes, in this context you should not use a PERFORM > > PL/pgSQL protect you before useless queries - so you can use a CTE without > returned result directly or CTE with result via PERFORM statement (and in > this case it must be unmodifing CTE

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On Aug 20, 2013, at 2:44 PM, Pavel Stehule wrote: > I think the way forward is to remove the restriction such that data > returning queries must be PERFORM'd > > I disagree, current rule has sense. Perhaps a DECLARE FUNCTION attribute that turns off the functionality, then? Best, David --

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On Aug 20, 2013, at 2:53 PM, Pavel Stehule wrote: >> I am passing the values returned from a CTE to a call to pg_notify(). I do >> not care to collect the output of pg_notify(), which returns VOID. > > it is little bit different issue - PL/pgSQL doesn't check if returned type is > VOID - it ca

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On Aug 20, 2013, at 3:05 PM, Pavel Stehule wrote: > When you would to ignore result, then you should to use a PERFORM - actually, > it is limited now and should be fixed. Have no problem with it. Glad to have you on board. :-) > I don't would to enable a free unbound statement that returns res

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On Aug 20, 2013, at 3:18 PM, Pavel Stehule wrote: > can you show some examples, please This is not dissimilar to what I am actually doing: CREATE TABLE foo (id SERIAL PRIMARY KEY, name TEXT); CREATE OR REPLACE FUNCTION shipit ( VARIADIC things TEXT[] ) RETURNS BOOL LANGUAGE

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On Aug 20, 2013, at 3:38 PM, Pavel Stehule wrote: > pg_notify returns void, so there are no necessary casting to void > > so enhanced check - so all returned columns are void should be enough What if I call another function I wrote myself that returns an INT, but I do not care about the INT? M

[HACKERS] CAST Within EXCLUSION constraint

Hackers, I am trying to do something like this: CREATE TYPE source AS ENUM( 'fred', 'wilma', 'barney', 'betty' ); CREATE EXTENSION btree_gist; CREATE TABLE things ( source source NOT NULL, within tstzrange NOT NULL, EXCLUDE USING gist (source WITH

Re: [HACKERS] CAST Within EXCLUSION constraint

On Aug 20, 2013, at 6:50 PM, Tom Lane wrote: > You need more parentheses -- (source::text) would've worked. Alas, no, same problem as for CAST(): ERROR: functions in index expression must be marked IMMUTABLE >> No problem, I can use CAST(), right? So I try: >>EXCLUDE USING gist (CAS

Re: [HACKERS] CAST Within EXCLUSION constraint

On Aug 21, 2013, at 4:13 PM, Tom Lane wrote: >> test=# create cast (source as oid) without function; >> ERROR: enum data types are not binary-compatible > > The reason for that is you'd get randomly different results on another > installation. In this particular application, I think David does

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On Aug 23, 2013, at 8:51 PM, Pavel Stehule wrote: > it is about a personal taste - if you prefer more verbose or less verbose > languages. > > I feeling a PERFORM usage as something special and you example is nice case, > where I am think so PERFORM is good for verbosity. I really do not see

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On Aug 27, 2013, at 12:30 AM, Pavel Stehule wrote: > I disagree - Tom K. speaking about what he likes or dislikes (and about what > he didn't use) He forgot about strong points of implicit result or > interesting points. Clients usually has no problem with dynamic datasets - > PHP, DBI, Llibpq

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On Aug 27, 2013, at 1:36 PM, Pavel Stehule wrote: > I agree with David that we should use some new syntax to specify > return-results-directly-to-client, assuming we ever get any such > functionality. It seems like a pretty bad choice of default behavior, > which is essentially what you're sayin

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On Aug 27, 2013, at 3:10 PM, Pavel Stehule wrote: > CREATE PROCEDURE foo() > BEGIN > SELECT 1,2; > SELECT 2; > SELECT 3,4 > END; > > And is not strange expect a result > > CALL foo() > > 1,2 > 2 > 3,4 > > Procedure is a script (batch) moved to server side for better performance and > b

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On Aug 29, 2013, at 1:11 PM, Pavel Stehule wrote: > I cannot to say what is good design for PL/pgSQL - only I feel so some > variant of RETURN statement is not good, because semantic is significantly > different. And I see a increasing inconsistency between a original ADA and > PL/pgSQL. So

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On Aug 29, 2013, at 2:22 PM, Pavel Stehule wrote: > Still I don't think so correct solution is enabling a unbound SELECTs, but > correct is a fix a PERFORM and remove a necessity to use a PERFORM for call > of VOID functions. Well, in this thread, I believe you are the only person who feels th

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On Aug 29, 2013, at 2:41 PM, Pavel Stehule wrote: > I am thinking, so I propose a enough solution for you - when you use CTE for > execution of VOID function, then result vill be VOID set, what we can accept > as undefined result, and in this case a PERFORM should not be required. If > CTE wil

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On Aug 29, 2013, at 2:48 PM, Andres Freund wrote: >> You have yet to supply any arguments which support this position. > > I am not convinced that's enough of a reason, but the requirement to use > PERFORM for SELECTs that aren't stored anywhere actually has prevented > bugs for me. I am not con

[HACKERS] No Index-Only Scan on Partial Index

Hackers, I was trying to figure out why a query was not doing an index-only scan on a partial index, when Josh Berkus pointed to this issue, reported by Merlin Moncure: http://www.postgresql.org/message-id/CAHyXU0x1OGao48WajAfUsbXqkUDLf=_6ho6hlmb8dsfkwda...@mail.gmail.com In short, the plan

Re: [HACKERS] No Index-Only Scan on Partial Index

On Oct 1, 2013, at 3:56 PM, Merlin Moncure wrote: > I don't think it has anything to do with the conditional index -- it's > the functional based. For some reason postgres always wants to post > filter (note the filter step below): > > postgres=# create index on try(upper_inf(irange)); > CREATE

Re: [HACKERS] No Index-Only Scan on Partial Index

On Oct 2, 2013, at 5:07 AM, Merlin Moncure wrote: > > Hrm. I get a seq scan for that query: > > > > create index on try(upper_inf(irange)); > > explain select * from try where upper_inf(irange); > > QUERY PLAN > > ---

Re: [HACKERS] No Index-Only Scan on Partial Index

On Oct 3, 2013, at 10:50 AM, Josh Berkus wrote: >> >> But anyway, I still don’t understand why, if the function used to store the >> value is immutable (as upper_inf() is), why Postgres doesn't do an index >> scan. Is this something that could be improved in the planner? > > Yes. This is cle

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

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] [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] 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] 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] WIP patch for parameterized inner paths

On Jan 25, 2012, at 10:24 AM, Tom Lane wrote: > Anyway, I'd be willing to hold off committing if someone were to > volunteer to test an unintegrated copy of the patch against some > moderately complicated application. But it's a sufficiently large > patch that I don't really care to sit on it and

Re: [HACKERS] WIP patch for parameterized inner paths

On Jan 25, 2012, at 12:19 PM, Tom Lane wrote: >> Why not create a branch? IIRC the build farm can be configured to run >> branches. > > I already know what the patch does against the regression tests. > Buildfarm testing is not of interest here. What would be of help is, > say, Kevin volunteeri

Re: [HACKERS] Inline Extension

On Jan 26, 2012, at 9:40 AM, Dimitri Fontaine wrote: > So I'm going to prepare the next version of the patch with this design: > > - in catalog extension scripts for inline extension > > pg_extension_script(extoid, oldversion, version, script) > > oldversion is null when create extension is

Re: [HACKERS] Inline Extension

On Jan 27, 2012, at 2:19 AM, Cédric Villemain wrote: >> Also --exclude-extension? > > It might be the default. > We need something to dump the content of > pg_catalog.pg_extension_script (or whatever table is going to contain > SQL code), per extension or all. I think dim said --no-extensions wo

[HACKERS] Access Error Details from PL/pgSQL

Hackers, In PL/pgSQL exception handling, I'm able to access the error code (SQLSTATE) and error message (SQLERRM). Is there any way to get at error details (yet)? If not, could SQLDETAIL or some such be added? Thanks, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)

Re: [HACKERS] Access Error Details from PL/pgSQL

On Feb 13, 2012, at 9:30 AM, Pavel Stehule wrote: > no in stable > > http://www.depesz.com/2011/07/20/waiting-for-9-2-stacked-diagnostics-in-plpgsql/ Ah, great, I had forgotten about that. Thank you, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes

Re: [HACKERS] Triggers with DO functionality

On Feb 17, 2012, at 5:22 AM, Thom Brown wrote: > The purpose being to only have a single statement to set up the > trigger rather than setting up a separate trigger function which will > unlikely be re-used by other triggers... or is this of dubious > benefit? +1, though I imagine it would just g

[HACKERS] Review: alternate psql file locations

Reference: http://archives.postgresql.org/message-id/4f00ca9e.9000...@dunslane.net This patch adds support for two new environment variables: PSQL_HISTORY: Alternative location for the command history file. PSQLRC: Alternative location of the user's .psqlrc file. The context diff patch applies

[HACKERS] Document hashtext() and Friends?

Hackers, Is there a reason that hashtext() and friends are not documented? Given that they’re likely to be used more and more for partitioning and sharding, I think it would be useful to do so, starting with something like this. Comments? *** a/doc/src/sgml/func.sgml --- b/doc/src/sgml/func.sgm

Re: [HACKERS] Document hashtext() and Friends?

On Feb 21, 2012, at 12:11 PM, Michael Glaesemann wrote: > And hashtext *has* changed across versions, which is why Peter Eisentraut > published a version-independent hash function library: > https://github.com/petere/pgvihash Yes, Marko wrote one, too: https://github.com/markokr/pghashlib B

Re: [HACKERS] Document hashtext() and Friends?

On Feb 21, 2012, at 12:14 PM, David E. Wheeler wrote: >> And hashtext *has* changed across versions, which is why Peter Eisentraut >> published a version-independent hash function library: >> https://github.com/petere/pgvihash > > Yes, Marko wrote one, too: > &g

Re: [HACKERS] overriding current_timestamp

On Feb 23, 2012, at 3:08 AM, Peter Eisentraut wrote: > For (unit) testing, I have often had the need to override the current > timestamp in the database system. For example, a column default, > function, or views would make use of the current timestamp in some way, > and to test the behavior, it'

Re: [HACKERS] overriding current_timestamp

On Feb 23, 2012, at 10:54 AM, David E. Wheeler wrote: > I create a "mock" schema, add the function to it, and then put it in the > search_path ahead of pg_catalog. See the example starting at slide 48 on > http://www.slideshare.net/justatheory/pgtap-best-practices. Sorry, st

[HACKERS] row_to_json() Bug

Looks like row_to_json() thinks 0s are nulls: postgres=# select row(0); row - (0) (1 row) postgres=# SELECT row_to_json(row(0)); row_to_json - {"f1":null} (1 row) Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@p

Re: [HACKERS] row_to_json() Bug

On Feb 23, 2012, at 8:49 PM, Andrew Dunstan wrote: > Fixed, Thanks for the report. (Also fixed in my 9.1 backport). Awesome, thanks, will try it tomorrow. David smime.p7s Description: S/MIME cryptographic signature

Re: [HACKERS] overriding current_timestamp

On Feb 27, 2012, at 4:29 AM, Peter Eisentraut wrote: >> I create a "mock" schema, add the function to it, and then put it in the >> search_path ahead of pg_catalog. > > That doesn't work for current_timestamp and similar built-in functions, > because they are always mapped to the pg_catalog sche

Re: [HACKERS] overriding current_timestamp

On Feb 27, 2012, at 4:29 AM, Peter Eisentraut wrote: >> Sorry, starting at slide 480. > > That presentation only goes to slide 394. Crimony, sorry, this presentation: http://www.slideshare.net/justatheory/test-drivern-database-development Note that I put pg_catalog at the end of the search_p

Re: [HACKERS] leakproof

On Feb 26, 2012, at 4:53 AM, Peter Eisentraut wrote: >> I also liked Kevin's suggestion of DISCREET > > That would probably create too much confusion with "discrete". SECRETE? David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: ht

Re: [HACKERS] overriding current_timestamp

On Feb 27, 2012, at 11:39 AM, Peter Eisentraut wrote: >> I use it for NOW() all the time. > > But it won't work for current_timestamp. Why not? Not challenging your assertion here, just curious why it’s different. David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To

Re: [HACKERS] overriding current_timestamp

On Feb 27, 2012, at 11:43 AM, Peter Eisentraut wrote: >> Why not? Not challenging your assertion here, just curious why it’s >> different. > > Because it's not actually a function, it's hardcoded in the grammar to > call pg_catalog.now(). Ah, I see. Pity. David -- Sent via pgsql-hackers maili

Re: [HACKERS] pgsql_fdw, FDW for PostgreSQL server

On Feb 28, 2012, at 8:20 AM, Robert Haas wrote: > I liked the shorter name, myself, but I'm not going to make a big deal about > it. pg_ is used quite a bit. what about pg_fdw? David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: htt

[HACKERS] Custom Operators Cannot be Found for Composite Type Values

Hackers, I’m doing some development with the new JSON type (actually, Andrew’s backport to 9.1) and needed to do some very basic equivalence testing. So I created a custom operator: CREATE OR REPLACE FUNCTION json_eq( json, json ) RETURNS BOOLEAN LANGUAGE SQL STRICT IMMU

Re: [HACKERS] Custom Operators Cannot be Found for Composite Type Values

On Mar 7, 2012, at 8:23 PM, Tom Lane wrote: > You have not told the system that your operator is equality for the > datatype. It's just a random operator that happens to be named "=". > We try to avoid depending on operator names as cues to semantics. > > You need to incorporate it into a defaul

Re: [HACKERS] Custom Operators Cannot be Found for Composite Type Values

On Mar 8, 2012, at 11:16 AM, Tom Lane wrote: >> This seems to work. > > Urk. You really ought to provide the whole opclass (all 5 operators). > I'm not sure what will blow up if you leave it like that, but it won't > be pretty. Yes, I expect to have to fill in gaps as I go. These are just for u

Re: [HACKERS] Custom Operators Cannot be Found for Composite Type Values

On Mar 8, 2012, at 11:27 AM, Andrew Dunstan wrote: > Yeah. Note too that this is at best dubious: > >CREATE OR REPLACE FUNCTION json_cmp( >json, >json >) RETURNS INTEGER LANGUAGE SQL STRICT IMMUTABLE AS $$ >SELECT bttextcmp($1::text, $2::text); >$$; > > > Two

Re: [HACKERS] regress bug

On Mar 8, 2012, at 10:22 AM, Andrew Dunstan wrote: > This seems like an outright bug. I don't recall any discussion on it. Maybe > nobody's come across it before. ISTM the correct behaviour would be to put > converted sql files in $inputdir/sql and converted results files in > $outputdir/expect

Re: [HACKERS] regress bug

On Mar 8, 2012, at 12:20 PM, Andrew Dunstan wrote: > It works fine if you don't need to do any file conversions (i.e. if you don't > have "input" or "output" directories). But file_textarray_fdw does. > > Here's a patch that I think fixes the problem. While you’re there, an issue I noticed is t

Re: [HACKERS] regress bug

On Mar 8, 2012, at 12:59 PM, Tom Lane wrote: > Huh? MODULE_PATHNAME is not substituted by pg_regress at all (anymore > anyway). Yeah, sorry, I meant `make`. > There's still some vestigial support for it in pgxs.mk, but > the future of that code is to vanish, not get improved. You should > not

Re: [HACKERS] regress bug

On Mar 8, 2012, at 1:45 PM, Andrew Dunstan wrote: >> So perhaps DATA_built is to be removed from pgxs.mk? And if so, is the idea >> then that one should just put the module name in the .sql file, rather than >> MODULE_PATHNAME in a .sql.in file? > > Extensions (unlike non-extension modules) sho

Re: [HACKERS] elegant and effective way for running jobs inside a database

On Mar 9, 2012, at 7:55 AM, Merlin Moncure wrote: > 100% agree (having re-read the thread and Alvaro's idea having sunk > in). Being able to set up daemon processes side by side with the > postmaster would fit the bill nicely. It's pretty interesting to > think of all the places you could go wi

[HACKERS] Advisory Lock BIGINT Values

Hackers, The documentation for pg_locks says that, for BIGINT advisory locks: > A bigint key is displayed with its high-order half in the classid column, its > low-order half in the objid column I was in need of knowing what the bigint is that is waiting on a lock, and Andrew Dunstan was kind

Re: [HACKERS] Finer Extension dependencies

On Mar 29, 2012, at 4:42 AM, Robert Haas wrote: > 2. Add a new feature to the provides line with every release that does > anything other than fix bugs, leading to: > > provides = foobar-1.1, foobar-1.2, foobar-1.3, foobar-1.4, foobar-1.5, > foobar-1.6, foobar-2.0, foobar-2.1, foobar-2.2, foobar-

Re: [HACKERS] Finer Extension dependencies

On Mar 29, 2012, at 11:48 AM, Robert Haas wrote: > Frankly, I'm not sure we bet on the right horse in not mandating a > version numbering scheme from the beginning. But given that we > didn't, we probably don't want to get too forceful about it too > quickly. However, we could ease into it by do

Re: [HACKERS] Finer Extension dependencies

On Apr 2, 2012, at 11:24 AM, Peter Eisentraut wrote: > Or an extension could specify itself which version numbering scheme it > uses. This just has to be a reference to a type, which in turn could be > semver, debversion, or even just numeric or text (well, maybe name). > Then you'd just need to

Re: [HACKERS] Finer Extension dependencies

On Apr 2, 2012, at 11:58 AM, Tom Lane wrote: >> Sounds like a lot of work for core to maintain various version comparison >> schemes > > Well, the primary argument for avoiding version comparison semantics to > begin with was exactly that we didn't want to mandate a particular > version-numberin

Re: [HACKERS] Unsigned integer types

On May 29, 2013, at 10:48 AM, Fabien COELHO wrote: > If you do it, having uint1 (1 byte) would be nice as well. There is a signed 1byte int on PGXN, FWIW: http://pgxn.org/extension/tinyint Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes

Re: [HACKERS] Perl 5.18 breaks pl/perl regression tests?

On Jun 3, 2013, at 7:31 AM, Tom Lane wrote: > Hah. That leads to > http://perl5.git.perl.org/perl.git/commitdiff/451f421 > in which it's said "What happens is that eval tacks "\n;" on to the end > of the string if it does not already end with a semicolon." > > So we could likely hide the cross-

  1   2   3   4   5   6   7   8   9   10   >