Re: [HACKERS] [PATCH] WIP Add ALWAYS DEFERRED option for constraints

På onsdag 04. oktober 2017 kl. 00:24:19, skrev Vik Fearing < vik.fear...@2ndquadrant.com <mailto:vik.fear...@2ndquadrant.com>>: On 10/03/2017 10:10 PM, Andreas Joseph Krogh wrote: > While we're in deferrable constraints land...; > I even more often need deferrable /cond

Re: [HACKERS] [PATCH] WIP Add ALWAYS DEFERRED option for constraints

rted: CREATE UNIQUE INDEX some_uk ON email_folder(owner_id, folder_type, name) WHERE parent_idIS NULL DEFERRABLE INITIALLY DEFERRED;   Are there any plans to support this?   Thanks.   -- Andreas Joseph Krogh  

Re: [HACKERS] Clarification in pg10's pgupgrade.html step 10 (upgrading standby servers)

På mandag 18. september 2017 kl. 16:28:07, skrev Bruce Momjian mailto:br...@momjian.us>>: On Sat, Sep 16, 2017 at 11:36:40PM +0200, Andreas Joseph Krogh wrote: > På lørdag 16. september 2017 kl. 18:34:51, skrev Bruce Momjian < > br...@momjian.us>: >     No.  If you ran in

Re: [HACKERS] Clarification in pg10's pgupgrade.html step 10 (upgrading standby servers)

På lørdag 16. september 2017 kl. 18:34:51, skrev Bruce Momjian mailto:br...@momjian.us>>: On Sat, Sep 16, 2017 at 06:11:17PM +0200, Andreas Joseph Krogh wrote: > I'm a little unsure what scenario we're trying to describe here. Copying the > pg_wal separately (for which ther

Re: [HACKERS] Clarification in pg10's pgupgrade.html step 10 (upgrading standby servers)

På lørdag 16. september 2017 kl. 17:24:14, skrev Bruce Momjian mailto:br...@momjian.us>>: On Fri, Sep 15, 2017 at 01:23:45AM +0200, Andreas Joseph Krogh wrote: > I tested upgrading from 9.6 to 10 now, using pg_upgrade, and pg_upgrade creates > the new data-dir with pg_wal "

Re: [HACKERS] Clarification in pg10's pgupgrade.html step 10 (upgrading standby servers)

På torsdag 14. september 2017 kl. 21:13:56, skrev Bruce Momjian < br...@momjian.us <mailto:br...@momjian.us>>: On Thu, Sep 14, 2017 at 08:49:24PM +0200, Andreas Joseph Krogh wrote: >     I think the tablespace example is clear enough to modify for WAL and we >     instruct the

Re: [HACKERS] Clarification in pg10's pgupgrade.html step 10 (upgrading standby servers)

På torsdag 14. september 2017 kl. 20:39:34, skrev Bruce Momjian < br...@momjian.us <mailto:br...@momjian.us>>: On Wed, Sep 13, 2017 at 04:31:09PM +0200, Andreas Joseph Krogh wrote: > På onsdag 13. september 2017 kl. 15:26:27, skrev Bruce Momjian < > br...@momjian.us>:

Re: [HACKERS] Clarification in pg10's pgupgrade.html step 10 (upgrading standby servers)

På onsdag 13. september 2017 kl. 15:26:27, skrev Bruce Momjian mailto:br...@momjian.us>>: On Wed, Sep 13, 2017 at 01:35:17AM +0200, Andreas Joseph Krogh wrote: [snip] > I know I'm being a little nitty-gritty here, but if it helps me understand it > might help others. I

Re: [HACKERS] Clarification in pg10's pgupgrade.html step 10 (upgrading standby servers)

På onsdag 13. september 2017 kl. 01:54:15, skrev Stephen Frost < sfr...@snowman.net <mailto:sfr...@snowman.net>>: Andreas, * Andreas Joseph Krogh (andr...@visena.com) wrote: > I have to ask; Why not run pg_upgrade on standby, after verifying that it's in > sync with p

Re: [HACKERS] Clarification in pg10's pgupgrade.html step 10 (upgrading standby servers)

PG to realize they should do. Thanks! Stephen     Thanks for th explaination.   I have to ask; Why not run pg_upgrade on standby, after verifying that it's in sync with primary and promoting it to primary if necessary and then making it standby again after pg_upgrade is finished

Re: [HACKERS] Clarification in pg10's pgupgrade.html step 10 (upgrading standby servers)

På onsdag 13. september 2017 kl. 01:00:20, skrev Bruce Momjian mailto:br...@momjian.us>>: On Wed, Sep 13, 2017 at 12:40:32AM +0200, Andreas Joseph Krogh wrote: > På tirsdag 12. september 2017 kl. 23:52:02, skrev Bruce Momjian < > br...@momjian.us>: > >     On Tue, Se

Re: [HACKERS] Clarification in pg10's pgupgrade.html step 10 (upgrading standby servers)

På tirsdag 12. september 2017 kl. 23:52:02, skrev Bruce Momjian < br...@momjian.us <mailto:br...@momjian.us>>: On Tue, Sep 12, 2017 at 08:59:05PM +0200, Andreas Joseph Krogh wrote: >     Improvements? > > Thanks, that certainly improves things. > But; I still fin

Re: [HACKERS] Clarification in pg10's pgupgrade.html step 10 (upgrading standby servers)

På tirsdag 12. september 2017 kl. 21:11:45, skrev Robert Haas < robertmh...@gmail.com <mailto:robertmh...@gmail.com>>: On Tue, Sep 12, 2017 at 2:59 PM, Andreas Joseph Krogh wrote: > There are many ways to do/configure things it seems, resulting in many ifs > and buts whic

Re: [HACKERS] Clarification in pg10's pgupgrade.html step 10 (upgrading standby servers)

På tirsdag 12. september 2017 kl. 19:19:22, skrev Bruce Momjian < br...@momjian.us <mailto:br...@momjian.us>>: On Thu, Aug  3, 2017 at 11:37:32AM +0200, Michael Paquier wrote: > On Mon, Jul 31, 2017 at 6:13 PM, Robert Haas wrote: > > On Fri, Jul 28, 2017 at 10:35 AM,

Re: [HACKERS] Release Note changes

that case;   "If upgrading from a 9.4 server or later, and you don't use Large Objects, external utilities using logical decoding, such as pglogical or proprietary alternatives, can also provide an alternate route, often with lower downtime."   pg_upgrade or pg_dump is really the only option for us using LOs.   -- Andreas Joseph Krogh

[HACKERS] Clarification in pg10's pgupgrade.html step 10 (upgrading standby servers)

ed, and step 10-f should provide a clarer example with more detailed values for the directory-structures involved.   I really think section 10 needs improvement as I'm certainly not comfortable upgrading standbys following the existing procedure.   Thanks.   -- Andreas Joseph Krogh

Re: [HACKERS] CTE inlining

.pdf   PG is not on top wrt. CTE, but could have been if CTEs were not this "established" fence.   +1 for removing this fence and get all the possible optimization we can. -- Andreas Joseph Krogh  

Re: [HACKERS] Gather Merge

På fredag 10. mars 2017 kl. 10:34:48, skrev Rushabh Lathia < rushabh.lat...@gmail.com <mailto:rushabh.lat...@gmail.com>>:     On Fri, Mar 10, 2017 at 2:42 PM, Andreas Joseph Krogh mailto:andr...@visena.com>> wrote: På fredag 10. mars 2017 kl. 10:09:22, skrev Rushabh Lathia

Re: [HACKERS] Gather Merge

På fredag 10. mars 2017 kl. 10:09:22, skrev Rushabh Lathia < rushabh.lat...@gmail.com <mailto:rushabh.lat...@gmail.com>>:     On Fri, Mar 10, 2017 at 2:33 PM, Andreas Joseph Krogh mailto:andr...@visena.com>> wrote: [...] The execution-plan seems (unsurprisingly) to depend on

Re: [HACKERS] Gather Merge

På fredag 10. mars 2017 kl. 09:53:47, skrev Rushabh Lathia < rushabh.lat...@gmail.com <mailto:rushabh.lat...@gmail.com>>:     On Fri, Mar 10, 2017 at 1:44 PM, Andreas Joseph Krogh mailto:andr...@visena.com>> wrote: På torsdag 09. mars 2017 kl. 18:09:45, skrev Robert Ha

Re: [HACKERS] Gather Merge

 │ │ Execution time: 170.859 ms        │     -- Andreas Joseph Krogh  

[HACKERS] Error building docs

es.sgml:14:19:E: element "BOOK" undefined osx:postgres.sgml:15:7:E: element "TITLE" undefined osx:postgres.sgml:17:10:E: element "BOOKINFO" undefined osx:postgres.sgml:18:13:E: element "CORPAUTHOR" undefined osx:postgres.sgml:19:14:E: element "PRODUC

Re: [HACKERS] [GENERAL] Select works only when connected from login postgres

Yes, I have a tendency to use emacs sub-shells (and occasionally M-x sql-postgres)-- I thought I'd reproduced the behavior in an xterm, but I was just trying again and I don't see it. It does seem that the dumbness of my dumb terminal is a factor. If I understand the way this works, it could be

Re: [HACKERS] Move pg_largeobject to a different tablespace *without* turning on system_table_mods.

På onsdag 19. oktober 2016 kl. 18:44:24, skrev Tom Lane mailto:t...@sss.pgh.pa.us>>: Andreas Joseph Krogh writes: > På onsdag 19. oktober 2016 kl. 18:29:31, skrev Bruce Momjian   I think an open question is why you would not want to move the other >  system tables at the same t

Re: [HACKERS] Move pg_largeobject to a different tablespace *without* turning on system_table_mods.

På onsdag 19. oktober 2016 kl. 18:42:11, skrev Bruce Momjian mailto:br...@momjian.us>>: On Wed, Oct 19, 2016 at 06:33:55PM +0200, Andreas Joseph Krogh wrote: > På onsdag 19. oktober 2016 kl. 18:29:31, skrev Bruce Momjian >: > >     On Tue, Oct 18, 2016 at 04:51:54PM +02

Re: [HACKERS] Move pg_largeobject to a different tablespace *without* turning on system_table_mods.

På onsdag 19. oktober 2016 kl. 18:29:31, skrev Bruce Momjian mailto:br...@momjian.us>>: On Tue, Oct 18, 2016 at 04:51:54PM +0200, Andreas Joseph Krogh wrote: >     > 2. Being able to move pg_largeobject to a different tablespace >     >    *without* turning on system_t

Re: [HACKERS] Move pg_largeobject to a different tablespace *without* turning on system_table_mods.

På tirsdag 18. oktober 2016 kl. 16:26:37, skrev Euler Taveira < eu...@timbira.com.br <mailto:eu...@timbira.com.br>>: On 18-10-2016 10:13, Andreas Joseph Krogh wrote: > From time to time pg_largeobject comes up as an issue with being > implemented as a system-catalog. &g

[HACKERS] Move pg_largeobject to a different tablespace *without* turning on system_table_mods.

one willing to discuss this?   Thanks.   -- Andreas Joseph Krogh CTO / Partner - Visena AS Mobile: +47 909 56 963 andr...@visena.com <mailto:andr...@visena.com> www.visena.com <https://www.visena.com> <https://www.visena.com>

Re: [HACKERS] pg_upgrade 9.5 -> 9.6 fails when pg_largeobject is in separate tablespace

På søndag 09. oktober 2016 kl. 23:43:23, skrev Robert Haas < robertmh...@gmail.com <mailto:robertmh...@gmail.com>>: On Sat, Oct 8, 2016 at 9:02 AM, Andreas Joseph Krogh mailto:andr...@visena.com>> wrote: (I've set allow_system_table_mods=on in postgresql.conf) Any conf

[HACKERS] pg_upgrade 9.5 -> 9.6 fails when pg_largeobject is in separate tablespace

O andreak andreak psql -U postgres -c "alter table pg_largeobject set tablespace andreak_lo" -d andreak Is this a bug or not a supported configuration by pg_upgraded? Any hints on how to proceed?   Thanks.   -- Andreas Joseph Krogh CTO / Partner - Visena AS Mobile: +47 909 56 963 andr...@visena.com <mailto:andr...@visena.com> www.visena.com <https://www.visena.com> <https://www.visena.com>

Re: [HACKERS] Bogus ANALYZE results for an otherwise-unique column with many nulls

anon onp_crm_activity act (cost=0.00..10591.45 rows=217245 width=8) (actualtime=0.186..139.016 rows=220147 loops=1) -> Hash (cost=262.35..262.35 rows=13711 width=4) (actual time=28.980..28.980 rows=13760 loops=1) Buckets: 16384Batches: 1 Memory Usage: 612kB -> Index Only Scan using onp_crm_project_pkeyon onp_crm_project proj (cost=0.29..262.35 rows=13711 width= 4) (actual time=0.067..26.575 rows=13760 loops=1) Heap Fetches: 6146 Planning time: 41.021 ms Execution time: 605.530 ms (60 rows)   That's 420195 / 605 = 695x speedup! Thanks!   -- Andreas Joseph Krogh CTO / Partner - Visena AS Mobile: +47 909 56 963 andr...@visena.com <mailto:andr...@visena.com> www.visena.com <https://www.visena.com> <https://www.visena.com>  

Re: [HACKERS] Bogus ANALYZE results for an otherwise-unique column with many nulls

  Will this then make it into the soon-to-be-released 9.5.4?   -- Andreas Joseph Krogh CTO / Partner - Visena AS Mobile: +47 909 56 963 andr...@visena.com <mailto:andr...@visena.com> www.visena.com <https://www.visena.com> <https://www.visena.com>  

Re: [HACKERS] Bogus ANALYZE results for an otherwise-unique column with many nulls

Batches: 1 Memory Usage: 69kB -> IndexScan using onp_crm_person_onp_id_idx on onp_crm_person logfor (cost =0.14..25.02rows=4515 width=8) (actual time=0.032..0.270 rows=119 loops=4) Filter: (NOT is_resource) Rows Removed by Filter: 8 Planning time: 2.443 ms Executiontime: 239.979 ms (38 rows)   A

Re: [HACKERS] ERROR: ORDER/GROUP BY expression not found in targetlist

På fredag 17. juni 2016 kl. 08:14:39, skrev Amit Kapila mailto:amit.kapil...@gmail.com>>: On Fri, Jun 17, 2016 at 11:39 AM, Andreas Joseph Krogh mailto:andr...@visena.com>> wrote: På torsdag 16. juni 2016 kl. 20:19:44, skrev Tom Lane mailto:t...@sss.pgh.pa.us>>: Amit Kapi

Re: [HACKERS] ERROR: ORDER/GROUP BY expression not found in targetlist

to use INT_MAX ... regards, tom lane   As of 4c56f3269a84a81461cc53941e0eee02fc920ab6 I'm still getting it in one of my queries: ORDER/GROUP BY expression not found in targetlist   Am I missing something?   I could dig into this further to reproduce if necessary.   -- Andreas Joseph Krog

Re: [HACKERS] 10.0

På fredag 13. mai 2016 kl. 18:22:00, skrev Magnus Hagander mailto:mag...@hagander.net>>: On Fri, May 13, 2016 at 5:42 PM, Andreas Joseph Krogh mailto:andr...@visena.com>> wrote: På fredag 13. mai 2016 kl. 17:05:23, skrev Robert Haas mailto:robertmh...@gmail.com>>: Hi, There

Re: [HACKERS] 10.0

lly fast FTS (with proper, index-backed, sorting etc.) - Pluggable storage-engines   Thanks.   -- Andreas Joseph Krogh  

Re: [HACKERS] max_parallel_degree > 0 for 9.6 beta

ybe it's time to ask the question if the settings should be optimized more for high-end HW and not som matchstick-box? I mean, most of the people I know who are responsible for databases run them on HW colser to high-end than low-end. I'm not sure why optimizing for low-end is such a great choice.   -- Andreas Joseph Krog  

Re: [HACKERS] max_parallel_degree > 0 for 9.6 beta

hen, at the end of beta, we can decide what the default should be.   +1   Not enabling it per default gives the signal "It's not safe".   -- Andreas Joseph Krogh CTO / Partner - Visena AS Mobile: +47 909 56 963 andr...@visena.com <mailto:andr...@visena.com> www.visena.com

Re: [HACKERS] Covering + unique indexes

På lørdag 09. april 2016 kl. 06:34:39, skrev Tom Lane mailto:t...@sss.pgh.pa.us>>: Andreas Joseph Krogh writes: > Any reason $subject didn't make it (commited but reverted)? See the thread on -committers.   Ah, thanks.   -- Andreas Joseph Krogh

[HACKERS] Covering + unique indexes

Any reason $subject didn't make it (commited but reverted)?   This is a great feature and lots of work seems to have been put into this patch along with quite some reviewing. It would be nice to know why -hackers think it's not ready for 9.6.   Thanks.   -- Andreas Joseph Krogh

Re: [HACKERS] [PATCH] Phrase search ported to 9.6

select 'fat'::tsquery *** 'cat'; ? Single '*' ?  That's close to regex, any number of tokens. And it saves rules about duplicating character. select 'fat'::tsquery ** 'cat'; select 'fat * cat'::tsquery; select 'fat * [3] cat'::tsqyery; -- for non-default distance.   What about ~> ?   -- Andreas Joseph Krogh

Re: [HACKERS] [PATCH] Phrase search ported to 9.6

På tirsdag 02. februar 2016 kl. 12:04:21, skrev Alvaro Herrera < alvhe...@2ndquadrant.com <mailto:alvhe...@2ndquadrant.com>>: Andreas Joseph Krogh wrote:    > Which seems to indicate it has received a fair amount of testing and is quite > stable. > Hopefully it in

Re: [HACKERS] [PATCH] Phrase search ported to 9.6

På tirsdag 02. februar 2016 kl. 09:20:06, skrev Oleg Bartunov < obartu...@gmail.com <mailto:obartu...@gmail.com>>:     On Tue, Feb 2, 2016 at 10:18 AM, Andreas Joseph Krogh mailto:andr...@visena.com>> wrote: På tirsdag 02. februar 2016 kl. 04:22:57, skrev Michael Paquier m

Re: [HACKERS] [PATCH] Phrase search ported to 9.6

d Oleg Bartunov in 2009, so all credit goes to them. Any feedback is welcome. This is not a small patch: 28 files changed, 2441 insertions(+), 380 deletions(-) And the last CF of 9.6 should not contain rather large patches. -- Michael     OTOH; It would be extremely nice to get this into 9.6.    

Re: [HACKERS] Triggers on transaction?

only run once, and on the last update of "col" so that it sees 'bar'.   -- Andreas Joseph Krogh CTO / Partner - Visena AS

Re: [HACKERS] Support for detailed description of errors cased by trigger-violations

På lørdag 08. november 2014 kl. 23:39:50, skrev Tom Lane mailto:t...@sss.pgh.pa.us>>: Andreas Joseph Krogh writes: > Hi. �� When working with Oracle it is possible to catch constraint-violations > caused by triggers using JDBC, but it seems this isn't possible using PG, s

[HACKERS] Support for detailed description of errors cased by trigger-violations

ports this fine, with details about which table, column etc. causing the violation. Is there any work going on or are there any plans to support similar info for violations caused by triggers?   Thanks.   -- Andreas Joseph Krogh CTO / Partner - Visena AS Mobile: +47 909 56 963 andr...@visen

Re: [HACKERS] nulls in GIN index

ftstext. plainto_tsquery('English', 'how are you') = '' and the ftstext of some rows is also = '' So why doesn't the index return all these rows when a null string is searched. I think you can see what im trying to achieve, how do I do it?   Use the

Re: [HACKERS] Setting PG-version without recompiling

På torsdag 03. juli 2014 kl. 16:16:01, skrev Tom Lane mailto:t...@sss.pgh.pa.us>>: Andreas Joseph Krogh writes: > Hi. �� I'm up for testing 9.4 but my JDBC-driver fails to connect due to PG's > minor-version string: "4beta1". Is it possible to set this somewhere

Re: [HACKERS] Setting PG-version without recompiling

På torsdag 03. juli 2014 kl. 11:13:44, skrev Abhijit Menon-Sen < a...@2ndquadrant.com >: At 2014-07-03 11:02:34 +0200, andr...@visena.com wrote: > > Is it possible to set this somewhere without > recompiling PG? I'm afraid not.   Ok   -- Andreas Jospeh Krogh CTO /

[HACKERS] Setting PG-version without recompiling

Hi.   I'm up for testing 9.4 but my JDBC-driver fails to connect due to PG's minor-version string: "4beta1". Is it possible to set this somewhere without recompiling PG?   Thanks.   -- Andreas Jospeh Krogh CTO / Partner - Visena AS Mobile: +47 909 56 963 andr...@visena.com

Re: [HACKERS] BDR-project

På onsdag 08. januar 2014 kl. 18:57:52, skrev Simon Riggs mailto:si...@2ndquadrant.com>>: On 25 December 2013 12:01, Andreas Joseph Krogh wrote: > Ref: > http://wiki.postgresql.org/wiki/BDR_Project > > Is implementing main BDR features into core Postgres a probable objec

[HACKERS] BDR-project

Hi hackers.   Ref: http://wiki.postgresql.org/wiki/BDR_Project   Is implementing main BDR features into core Postgres a probable objective to version 9.4?   Thanks.   -- Andreas Joseph Krogh       mob: +47 909 56 963 Senior Software Developer / CTO - OfficeNet AS - http://www.officenet.no

Re: [HACKERS] Covering Indexes

lumns. And I wonder if it would work well with expressions, too? David This is analogous to SQL Server's "include" : |CREATE NONCLUSTERED INDEX my_idx| |ON my_table (status)| |INCLUDE (someColumn, otherColumn)| Which is useful, but bloats the index. -- Andreas Joseph Krogh -

Re: [HACKERS] WIP: SP-GiST, Space-Partitioned GiST

-obvious here, but will this patch bring indexed substring-search to PG? So queries conceptually equal to this will be possible to index: WHERE som_col @@ ':substr1:&:substr2!substr3:' meaning "contains substr1" AND "ends with substr2" OR "starts with substr3&

Re: Initial Review: JSON contrib modul was: Re: [HACKERS] Another swing at JSON

Thanks for reviewing my patch! On Mon, Jul 4, 2011 at 7:10 AM, Bernd Helmle wrote: > +comment = 'data type for storing and manipulating JSON content' > > I'm not sure, if "manipulating" is a correct description. Maybe i missed it, > but i didn't see functions to manipulate JSON strings directly,

Re: [HACKERS] Another swing at JSON

On Fri, Jun 17, 2011 at 2:29 AM, Bernd Helmle wrote: > Joseph, are you able to remove the compatibility code for this CF? Done. Note that this module builds, tests, and installs successfully with USE_PGXS=1. However, building without USE_PGXS=1 produces the following: CREATE EXTENS

Re: [HACKERS] VARIANT / ANYTYPE datatype

On Wed, May 11, 2011 at 7:53 AM, Robert Haas wrote: > That's likely to be how it gets implemented, but you seem to have > missed the point of some of the discussion upthread: the big problem > with that is that someone might type "DROP TYPE foo", and when they > do, you need an efficient way to fi

Re: [HACKERS] potential bug in trigger with boolean params

På onsdag 11. mai 2011 kl 11:30:51 skrev Szymon Guz <mabew...@gmail.com>: On 11 May 2011 11:01, Andreas Joseph Krogh <andr...@officenet.no> wrote: På onsdag 11. mai 2011 kl 10:56:19 skrev <t...@fuzzy.cz>:   > > Hi, > > I was trying to create a trigger with para

Re: [HACKERS] potential bug in trigger with boolean params

true' is > not one of them (TRUE is). See this: > > http://www.postgresql.org/docs/9.0/interactive/datatype-boolean.html What are you trying to accomplish? "CREATE OR REPLACE FUNCTION trigger_x()" does not declare any formal-parameters, so calling it with arguments doesn

Re: [HACKERS] VARIANT / ANYTYPE datatype

On Tue, May 10, 2011 at 10:29 PM, Joseph Adams wrote: > The VARIANT type, or similar, would be useful for the JSON data type > I've been intermittently working on, as it would allow us to create a > function like this: > >    from_json(JSON) returns VARIANT This occurred

Re: [HACKERS] VARIANT / ANYTYPE datatype

It seems to me a reasonable way to implement VARIANT would be to have a data type called VARIANT that stores an OID of the inner type at the beginning, followed by the binary data. When you say pg_typeof(somevariant), you'll get 'variant'. Instead, you'd use a function like this: variant_typ

[HACKERS] clog_redo causing very long recovery time

I'm working with a client that uses Postgres on what amounts to an appliance. The database is therefore subject to occasional torture such as, in this particular case, running out of disk space while performing a million plus queries (of mixed varieties, many using plpgsql with exception handling

Re: [HACKERS] cast from integer to money

Attached is an updated version of the patch to allow conversion of int4/int8 directly to money. I added overflow checks, dropped int2->cash, and updated the documentation. - Joey diff --git a/doc/src/sgml/datatype.sgml b/doc/src/sgml/datatype.sgml index ecc79e2..13b888d 100644 --- a/doc/src/sgml

Re: [HACKERS] cast from integer to money

On Sun, Apr 3, 2011 at 11:23 PM, Robert Haas wrote: > Thanks for the patch, but I think you forgot to worry about overflow: > > rhaas=# select 9223372036854775807::money; >  money > >  -$1.00 > (1 row) cash_in doesn't test for overflow, either (tested on 8.4.0, 9.0.3, and HEAD): joey=#

Re: [HACKERS] psql 9.1 alpha5: connection pointer is NULL

2011/4/2 Devrim GÜNDÜZ : > > I'm getting the following message after upgrading to Alpha5 on my Fedora > 14 box: > > $ psql -p 5433 > psql: connection pointer is NULL > > which comes from libpq. Server is running, and I can connect it to via > 9.0's psql. > > This is a regular RPM build. Am I doing

Re: [HACKERS] cast from integer to money

On Thu, Mar 31, 2011 at 6:39 PM, Stephen Frost wrote: > Going just integer->money, with the "1" -> "$1.00", seems completely > reasonable to me.  As for being too late in the cycle..  if someone's > willing to do the work, I can't imagine it breaking anything, so I > wouldn't be against putting it

Re: [HACKERS] Another swing at JSON

On Tue, Mar 29, 2011 at 4:02 PM, Dimitri Fontaine wrote: > Here's the ugly trick from ip4r, that's used by more extension: > > PREFIX_PGVER = $(shell echo $(VERSION) | awk -F. '{ print $$1*100+$$2 }') Thanks. I applied a minor variation of this trick to the JSON module, so now it builds/installs

Re: [HACKERS] Another swing at JSON

On Tue, Mar 29, 2011 at 2:42 PM, Dimitri Fontaine wrote: > Joseph Adams writes: >> It would be nice if I could make a Makefile conditional that skips the >> relocatable test and loads init-pre9.1.sql if the new extension >> interface isn't available.  Is there a Make

Re: [HACKERS] Another swing at JSON

On Tue, Mar 29, 2011 at 2:42 PM, Dimitri Fontaine wrote: >> Also, should uninstall_json.sql be named something else, like >> json--uninstall--0.1.sql ? > > You don't need no uninstall script no more, try DROP EXTENSION json; and > DROP EXTENSION json CASCADE; It's there for pre-9.1, where DROP EX

Re: [HACKERS] Another swing at JSON

On Mon, Mar 28, 2011 at 1:48 PM, Robert Haas wrote: > On Mon, Mar 28, 2011 at 1:21 PM, Joseph Adams > wrote: >> Attached is a patch that adds a 'json' contrib module.  Although we >> may want a built-in JSON data type in the near future, making it a >> module

Re: [HACKERS] Re: making write location work (was: Efficient transaction-controlled synchronous replication)

On 3/24/11 8:16 AM, Kevin Grittner wrote: > Simon Riggs wrote: >> Robert Haas wrote: > >>> At least as I understand it, it's not our project policy to carry >>> around code that doesn't accomplish anything useful. I have no >>> objection to keeping the field; I simply think that if we're >>> go

[HACKERS] patch: Add PGXS support to hstore's Makefile (trivial)

I discovered today that hstore's Makefile currently does not support PGXS; namely, the ability to install it like so: USE_PGXS=1 make sudo USE_PGXS=1 make install Moreover, hstore is the *only* contrib module whose Makefile does not contain "PGXS". The attached patch changes hstore's Mak

Re: [HACKERS] JSON data type status?

On Thu, Jan 20, 2011 at 8:13 PM, Itagaki Takahiro wrote: > On Fri, Jan 21, 2011 at 09:11, Bruce Momjian wrote: >> What happened to our work to add a JSON data type for PG 9.1? > > Nothing will happen in 9.1. > I assume we are in "competition" status: > > http://archives.postgresql.org/pgsql-hacke

Re: [HACKERS] patch: Add JSON datatype to PostgreSQL (GSoC, WIP)

On Tue, Oct 19, 2010 at 11:22 AM, Terry Laurenzo wrote: > Perhaps we should enumerate the attributes of what would make a good binary > encoding? Not sure if we're discussing the internal storage format or the binary send/recv format, but in my humble opinion, some attributes of a good internal f

Re: [HACKERS] Basic JSON support

On Mon, Oct 4, 2010 at 7:45 PM, Tom Lane wrote: > Yeah.  Joseph seems to be confusing copyrights with patents.  The idea > of "parse JSON with bison/flex" is not patentable by any stretch of the > imagination. What I meant is, anyone who sets out to write a JSON parser

Re: [HACKERS] Basic JSON support

On Mon, Sep 20, 2010 at 12:38 AM, Joseph Adams wrote: > Here's one thing I'm worried about: the bison/flex code in your patch > looks rather similar to the code in > http://www.jsonlint.com/bin/jsonval.tgz , which is licensed under the > GPL.  In particular, the incorrect nu

Re: [HACKERS] patch: Add JSON datatype to PostgreSQL (GSoC, WIP)

On Sat, Sep 18, 2010 at 4:03 PM, Robert Haas wrote: > Hmm, yeah.  I'd be tempted to try to keep the user's original > whitespace as far as possible, but disregard it as far as equality > comparison goes.  However, I'm not quite sure what the right thing to > do about 0 vs 0.0 is.  Does the JSON sp

Re: [HACKERS] patch: Add JSON datatype to PostgreSQL (GSoC, WIP)

On Fri, Sep 17, 2010 at 8:32 AM, Itagaki Takahiro wrote: > On Fri, Aug 13, 2010 at 7:33 PM, Joseph Adams > wrote: >> Updated patch: the JSON code has all been moved into core, so this >> patch is now for a built-in data type. > > I have a question about the design of

Re: [HACKERS] WIP: extensible enums

On Mon, Aug 23, 2010 at 1:54 PM, Tom Lane wrote: > "Andrew Dunstan" writes: >> On Mon, August 23, 2010 11:49 am, Alvaro Herrera wrote: >>> What do you need AFTER for?  Seems to me that BEFORE should be enough. >>> (You already have the unadorned syntax for adding an item after the last >>> one, w

Re: [HACKERS] JSON Patch for PostgreSQL - BSON Support?

On Mon, Aug 16, 2010 at 7:24 PM, Tom Lane wrote: > > Well, if it's not just a binary encoding of JSON, I think we can forget > about it ... certainly it won't work in the form I was visualizing. > >                        regards, tom lane I just read the spec, and BSON has a lot of bells and whi

Re: [HACKERS] JSON Patch for PostgreSQL - BSON Support?

On Sun, Aug 15, 2010 at 11:47 PM, Andrew Dunstan wrote: > > If BSON is simply in effect an efficient encoding of JSON, then it's not > clear to me that we would want another type at all. Rather, we might want to > consider storing the data in this supposedly more efficient format, and > maybe also

Re: [HACKERS] patch: General purpose utility functions used by the JSON data type

On Fri, Aug 13, 2010 at 2:02 PM, David Fetter wrote: > On Fri, Aug 13, 2010 at 01:33:06PM -0400, Robert Haas wrote: >> Maybe so, but it's not clear the interface that Joseph implemented is >> the one everyone wants... > > Fair enough.  What's the interface now in a

Re: [HACKERS] patch: General purpose utility functions used by the JSON data type

On Fri, Aug 13, 2010 at 10:46 AM, Robert Haas wrote: > On Fri, Aug 13, 2010 at 5:45 AM, Joseph Adams > wrote: >> getEnumLabelOids >>  * Useful-ometer: ()---o >>  * Rationale: There is currently no streamlined way to return a custom >>

[HACKERS] patch: General purpose utility functions used by the JSON data type

I factored out the general-purpose utility functions in the JSON data type code into a patch against HEAD. I have made a few changes to them since I posted about them earlier ( http://archives.postgresql.org/pgsql-hackers/2010-08/msg00692.php ). A summary of the utility functions along with some

Re: [HACKERS] patch: utf8_to_unicode (trivial)

On Tue, Jul 27, 2010 at 1:31 PM, Robert Haas wrote: > On Sat, Jul 24, 2010 at 10:34 PM, Joseph Adams > wrote: >> In src/include/mb/pg_wchar.h , there is a function unicode_to_utf8 , >> but no corresponding utf8_to_unicode .  However, there is a static >> function calle

[HACKERS] patch: utf8_to_unicode (trivial)

In src/include/mb/pg_wchar.h , there is a function unicode_to_utf8 , but no corresponding utf8_to_unicode . However, there is a static function called utf2ucs that does what utf8_to_unicode would do. I'd like this function to be available because the JSON code needs to convert UTF-8 to and from U

Re: [HACKERS] patch: Add JSON datatype to PostgreSQL (GSoC, WIP)

Update: I'm in the middle of cleaning up the JSON code ( http://git.postgresql.org/gitweb?p=json-datatype.git;a=summary if you want to see the very latest ), so I haven't addressed all of the major problems with it yet. On Fri, Jul 23, 2010 at 2:34 PM, Robert Haas wrote: > - I was under the impre

Re: [HACKERS] accentuated letters in text-search

On 07/22/2010 07:42 AM, Guillaume Lelarge wrote: Le 21/07/2010 23:23, Andreas Joseph Krogh a écrit : [...] I was googling for how to create a text-seach-config with the following properties: - Map unicode accentuated letters to an un-accentuated equivalent - No stop-words - Lowercase all

[HACKERS] accentuated letters in text-search

more googling I found this: http://www.sai.msu.su/~megera/wiki/unaccent Any reason the unaccent dict. and function did not make it in 9.0? -- Andreas Joseph Krogh Senior Software Developer / CTO +-+ OfficeNet AS| The

Re: [HACKERS] Review: Row-level Locks & SERIALIZABLE transactions, postgres vs. Oracle

On 7/17/10 12:09 PM, Kevin Grittner wrote: > Joe Conway wrote: > >> Should I be installing Florian's patch in addition to yours when I >> start testing? > > There's some manual fix-up needed, primarily because we need to > differentiate between SERIALIZABLE and REPEATABLE READ isolation > leve

Re: [HACKERS] extensible enum types

On Fri, Jun 18, 2010 at 1:59 PM, Andrew Dunstan wrote: > > > Robert Haas wrote: >> >> On Fri, Jun 18, 2010 at 12:59 PM, Andrew Dunstan >> wrote: >> >>> >>> You are just bumping up the storage cost. Part of the attraction of enums >>> is >>> their efficiency. >>> >> >> What's efficient about them?

[HACKERS] Should the JSON datatype be a specialization of text?

Currently, the JSON datatype (repository: http://git.postgresql.org/gitweb?p=json-datatype.git;a=summary ) is implemented somewhat like a specialization of TEXT, like XML is. I'm beginning to question if this is the right way to go. This doesn't concern whether the JSON datatype should retain the

Re: [HACKERS] hstore ==> and deprecate =>

On Fri, Jun 11, 2010 at 10:59 AM, Tom Lane wrote: > Peter Eisentraut writes: >> How about no operator at all?  It won't be as cool to read, but >> consider, the arguments are text and text, not involving any hstore type >> at all, so whatever operator you choose is in practice blocked from >> eve

Re: [HACKERS] Working with PostgreSQL enums in C code

On Fri, May 28, 2010 at 9:47 AM, Tom Lane wrote: > Robert Haas writes: >> On Fri, May 28, 2010 at 12:07 AM, Joseph Adams >> wrote: >>> I learned that to return an enum value from C, one needs to return the >>> OID of the right row of the pg_enum table.  I ev

Re: [HACKERS] functional call named notation clashes with SQL feature

On Fri, Jun 4, 2010 at 9:55 PM, Joseph Adams wrote: > If I had to choose between => and := for parameter naming, I'd go with > := because it seems more SQLish to me. On second thought, => might actually be a very intuitive syntax for defining dictionary types like hstore a

Re: [HACKERS] functional call named notation clashes with SQL feature

On Wed, May 26, 2010 at 9:28 PM, Tom Lane wrote: > Robert Haas writes: >> On Wed, May 26, 2010 at 8:21 PM, Tom Lane wrote: >>> If we go with the spec's syntax I think we'd have no realistic choice >>> except to forbid => altogether as an operator name.  (And no, I'm not >>> for that.) > >> I sup

[HACKERS] Working with PostgreSQL enums in C code

I encountered a situation while implementing JSON support where I needed to return an enum value from a C function. To clarify, here's the SQL: CREATE TYPE json_type_t AS ENUM ('null', 'string', 'number', 'bool', 'object', 'array'); CREATE OR REPLACE FUNCTION json_type(json) RETURNS json_type_t

Re: [HACKERS] JSON manipulation functions

I've started implementing the JSON datatype; the repo is at http://git.postgresql.org/gitweb?p=json-datatype.git . On Fri, May 14, 2010 at 1:15 PM, Robert Haas wrote: > On Thu, May 13, 2010 at 9:47 PM, Joseph Adams > wrote: >> Would it be a bad idea to give an enum and a funct

  1   2   3   >