Re: [HACKERS] Latch for the WAL writer - further reducing idle wake-ups.

On 03.05.2012 03:41, Robert Haas wrote: On Wed, May 2, 2012 at 7:21 PM, Tom Lane wrote: Adding any contention at all to XLogInsert doesn't seem like a smart idea, even if you failed to measure any problem in the specific tests you made. I wonder whether we could not improve matters by adding a

Re: [HACKERS] Future In-Core Replication

On 4/29/12 6:03 AM, Simon Riggs wrote: The DML-WITH-LIMIT-1 is required to do single logical updates on tables > with non-unique rows. > And as for any logical updates we will have huge performance problem > when doing UPDATE or DELETE on large table with no indexes, but > fortunately this pr

Re: [HACKERS] Re: xReader, double-effort (was: Temporary tables under hot standby)

On 4/29/12 9:27 AM, Kevin Grittner wrote: Maybe I can help with that by describing what the Wisconsin court system does for circuit court data. Thanks for the write-up, it was insightful. One thing I wanted to mention is that non-binary replication has an added advantage over binary from a DR

Re: [HACKERS] Torn page hazard in ginRedoUpdateMetapage()

Daniel Farina writes: > On Wed, May 2, 2012 at 6:06 PM, Noah Misch wrote: >> Can we indeed assume that all support-worthy filesystems align the start of >> every file to a physical sector? I know little about modern filesystem >> design, but these references leave me wary of that assumption: >>

Re: [HACKERS] Latch for the WAL writer - further reducing idle wake-ups.

On Wed, May 2, 2012 at 11:42 PM, Tom Lane wrote: > Robert Haas writes: >> ... It seems unlikely to cause any real >> problem if WAL writer takes a couple seconds to get with the program >> after a long period of inactivity; note that an async commit will kick >> it anyway, and a sync commit will

Re: [HACKERS] Torn page hazard in ginRedoUpdateMetapage()

On Wed, May 2, 2012 at 6:06 PM, Noah Misch wrote: > Can we indeed assume that all support-worthy filesystems align the start of > every file to a physical sector?  I know little about modern filesystem > design, but these references leave me wary of that assumption: > > http://www.mail-archive.com

Re: [HACKERS] Features of Postgresql and Postgres-xc with MySQL

Thanks this is very helpful Regards ViVek On Thu, May 3, 2012 at 4:57 AM, Michael Paquier wrote: > On Wed, May 2, 2012 at 2:37 PM, Vivek Singh Raghuwanshi < > vivekraghuwan...@gmail.com> wrote: > >> Please send me the link or white papers from where i can get information >> like. >> 3. Feature c

Re: [HACKERS] Latch for the WAL writer - further reducing idle wake-ups.

Robert Haas writes: > ... It seems unlikely to cause any real > problem if WAL writer takes a couple seconds to get with the program > after a long period of inactivity; note that an async commit will kick > it anyway, and a sync commit will probably half to flush WAL whether > the WAL writer wake

Re: [HACKERS] Torn page hazard in ginRedoUpdateMetapage()

On Mon, Apr 30, 2012 at 02:35:20PM -0400, Tom Lane wrote: > Noah Misch writes: > > When GIN changes a metapage, we WAL-log its ex-header content and never use > > a > > backup block. This reduces WAL volume since the vast majority of the > > metapage > > is unused. However, ginRedoUpdateMetapa

Re: [HACKERS] patch submission: truncate trailing nulls from heap rows to reduce the size of the null bitmap

On 5/2/12 10:20 AM, Jameison Martin wrote: > Attached are the following as per various requests: > * test_results.txt: the performance benchmarking results, > > * TestTrailingNull.java: the performance benchmarking code, with a few > additional scenarios as per various requests > >

Re: [HACKERS] Temporary tables under hot standby

Michael, > What is the use case for temporary tables on a hot standby server? > > Perhaps this is a noobie question, but it seems to me that a hot standby > server's use by* applications* or *users* should be limited to transactions > that don't alter the database in any form. A very common use

Re: [HACKERS] Latch for the WAL writer - further reducing idle wake-ups.

On Wed, May 2, 2012 at 7:21 PM, Tom Lane wrote: > It is getting a bit late to be considering such changes for 9.2, but > I'm willing to review and commit this if there's not anybody who feels > strongly that it's too late.  Personally I think it's in the nature of > cleanup and so fair game as lon

[HACKERS] Advisory locks seem rather broken

According to http://archives.postgresql.org/pgsql-general/2012-04/msg00374.php advisory locks now cause problems for prepared transactions, which ought to ignore them. It appears to me that this got broken by commit 62c7bd31c8878dd45c9b9b2429ab7a12103f3590, which marked the userlock lock method as

Re: [HACKERS] Features of Postgresql and Postgres-xc with MySQL

On Wed, May 2, 2012 at 2:37 PM, Vivek Singh Raghuwanshi < vivekraghuwan...@gmail.com> wrote: > Please send me the link or white papers from where i can get information > like. > 3. Feature comparison of PostgreSQL and Postgres-XC > 4. and can we use Postgres-XC in production with mission critical

Re: [HACKERS] Latch for the WAL writer - further reducing idle wake-ups.

Peter Geoghegan writes: > Attached patch latches up the WAL Writer, reducing wake-ups and thus > saving electricity in a way that is more-or-less analogous to my work > on the BGWriter: > http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=6d90eaaa89a007e0d365f49d6436f35d2392cfeb > I am

Re: [HACKERS] Unnecessary WAL archiving after failover

On Fri, Mar 23, 2012 at 10:03 AM, Fujii Masao wrote: > On second thought, I found other issues about WAL archiving after > failover. So let me clarify the issues again. > > Just after failover, there can be three kinds of WAL files in new > master's pg_xlog directory: > > (1) WAL files which were

Re: [HACKERS] proposal: additional error fields

"Kevin Grittner" writes: > Tom Lane wrote: >> "Kevin Grittner" writes: >>> That "F0" class looks suspicious; are those really defined by >>> standard or did we encroach on standard naming space with >>> PostgreSQL-specific values? >> I think we screwed up on that :-(. So we ought to renumber t

Re: [HACKERS] online debloatification (was: extending relations more efficiently)

On Wed, May 2, 2012 at 4:39 PM, Tom Lane wrote: > Robert Haas writes: >> Brainstorming wildly, how about something like this: > >> 1. Insert a new copy of the tuple onto some other heap page.  The new >> tuple's xmin will be that of the process doing the tuple move, and >> we'll also set a flag i

Re: [HACKERS] online debloatification (was: extending relations more efficiently)

Robert Haas writes: > Brainstorming wildly, how about something like this: > 1. Insert a new copy of the tuple onto some other heap page. The new > tuple's xmin will be that of the process doing the tuple move, and > we'll also set a flag indicating that a move is in progress. > 2. Set a flag on

[HACKERS] Modeling consumed shmem sizes, and some thorns

Hello List, I'd like to share with you some experiences we've had while investigating what we'd have to do to make very-very tiny databases. First, the formulae at http://www.postgresql.org/docs/9.1/static/kernel-resources.html#SHARED-MEMORY-PARAMETERS (17-2) seem misleading, particularly with re

Re: [HACKERS] How hard would it be to support LIKE in return declaration of generic record function calls ?

On Wed, May 2, 2012 at 12:06 PM, Peter Eisentraut wrote: > On ons, 2012-05-02 at 13:40 +0200, Hannu Krosing wrote: >> How hard would it be to add support for LIKE syntax, similar to table >> def in field list declaration for generic record functions >> >> What I'dd like to be able to do is to have

[HACKERS] PL/Python result set slicing broken in Python 3

This doesn't work anymore with Python 3: rv = plpy.execute(...) do_something(rv[0:1]) Apparently, they changed the C API for doing slicing, or rather made one of the two APIs for it silently do nothing. Details are difficult to find, but this email message seems to contain something:

[HACKERS] Beta time?

On Wed, May 02, 2012 at 01:15:48PM -0400, Tom Lane wrote: > Peter Eisentraut writes: > > On ons, 2012-05-02 at 00:31 -0400, Tom Lane wrote: > >> Checking this patch, I noticed that config.guess and config.sub harbor > >> most of the remaining references to those platforms, which reminded me: > >>

Re: [HACKERS] Have we out-grown Flex?

On Wed, May 02, 2012 at 10:37:58AM -0700, Jeff Janes wrote: > I could try to clean up and post the patch that implements this if you want. > > The second method was just to do --enable-profiling on a stock build > and look at the call graph section of gprof output. It attributed 50% > to pg_plan_

Re: [HACKERS] online debloatification (was: extending relations more efficiently)

On Wed, May 2, 2012 at 1:06 PM, Alvaro Herrera wrote: > Excerpts from Robert Haas's message of mié may 02 12:55:17 -0400 2012: >> On Wed, May 2, 2012 at 12:46 PM, Alvaro Herrera >> wrote: >> > Agreed.  Perhaps to solve this issue what we need is a way to migrate >> > tuples from later pages into

Re: [HACKERS] plpython crash (PG 92)

On lör, 2012-04-28 at 00:32 -0400, Tom Lane wrote: > I'm inclined to think that the best fix is for > PLy_spi_execute_fetch_result to copy the tupledesc into > TopMemoryContext, not the current context. This is a tad scary from a > memory leakage standpoint, but I suppose that if python fails to r

Re: [HACKERS] Patch pg_is_in_backup()

Hi Gilles, Sorry for the delay. Il 03/04/12 14:21, Gilles Darold ha scritto: +1, this is also my point of view. I have looked at the patch that contains both pg_is_in_backup() and pg_backup_start_time(). From a functional point of view it looks fine to me. I was thinking of addin

Re: [HACKERS] Have we out-grown Flex?

On Wed, May 2, 2012 at 3:33 PM, Peter Geoghegan wrote: > On 2 May 2012 04:57, Tom Lane wrote: >> FWIW, I think only developers not packagers would really be taking such >> a hit.  I assume we'd continue to ship prebuilt lexer output in >> tarballs, so there'd seldom be a reason for a packager to

Re: [HACKERS] Have we out-grown Flex?

On Wed, May 2, 2012 at 9:31 AM, Peter Geoghegan wrote: > On 2 May 2012 17:20, Jeff Janes wrote: >> For -S -M simple, the time spent planning is 5 times more than the >> time spent parsing.  It may be worthwhile to reduce the time spent >> parsing, but if the goal is parity with MySQL it probably

Re: [HACKERS] [COMMITTERS] pgsql: Remove dead ports

Peter Eisentraut writes: > On ons, 2012-05-02 at 00:31 -0400, Tom Lane wrote: >> Checking this patch, I noticed that config.guess and config.sub harbor >> most of the remaining references to those platforms, which reminded me: >> don't we usually update those files from autoconf upstream before be

Re: [HACKERS] [COMMITTERS] pgsql: Remove dead ports

On ons, 2012-05-02 at 00:31 -0400, Tom Lane wrote: > Peter Eisentraut writes: > > Remove dead ports > > Checking this patch, I noticed that config.guess and config.sub harbor > most of the remaining references to those platforms, which reminded me: > don't we usually update those files from autoc

Re: [HACKERS] extending relations more efficiently

Excerpts from Robert Haas's message of mié may 02 12:55:17 -0400 2012: > > On Wed, May 2, 2012 at 12:46 PM, Alvaro Herrera > wrote: > > Agreed.  Perhaps to solve this issue what we need is a way to migrate > > tuples from later pages into earlier ones.  (This was one of the points, > > never res

Re: [HACKERS] How hard would it be to support LIKE in return declaration of generic record function calls ?

On ons, 2012-05-02 at 13:40 +0200, Hannu Krosing wrote: > How hard would it be to add support for LIKE syntax, similar to table > def in field list declaration for generic record functions > > What I'dd like to be able to do is to have a generic json_to_record > function > > CREATE OR REPLACE RE

Re: [HACKERS] clog double-dip in heap_hot_search_buffer

On Wed, May 2, 2012 at 12:19 PM, Tom Lane wrote: > Robert Haas writes: >> On Wed, May 2, 2012 at 12:06 PM, Tom Lane wrote: >>> Otherwise this seems like a good idea. > >> Do you think I should apply this to 9.2, or wait until 9.3? > > We're not at beta yet, and it seems pretty safe/self-containe

Re: [HACKERS] extending relations more efficiently

On Wed, May 2, 2012 at 12:46 PM, Alvaro Herrera wrote: > Agreed.  Perhaps to solve this issue what we need is a way to migrate > tuples from later pages into earlier ones.  (This was one of the points, > never resolved, that we discussed during the VACUUM FULL rework.) Yeah, I agree. And frankly

Re: [HACKERS] extending relations more efficiently

Excerpts from Robert Haas's message of mié may 02 12:37:35 -0400 2012: > > On Wed, May 2, 2012 at 12:26 PM, Alvaro Herrera > wrote: > > Excerpts from Robert Haas's message of mié may 02 08:14:36 -0400 2012: > >> On Wed, May 2, 2012 at 7:16 AM, Jeroen Vermeulen wrote: > >> > On 2012-05-01 22:06,

Re: [HACKERS] extending relations more efficiently

Robert Haas writes: > On Wed, May 2, 2012 at 12:26 PM, Alvaro Herrera > wrote: >> Hm. I see those two things as different -- to me, bloat is unremoved >> dead tuples, whereas slack space would be free space that can be reused >> by new tuples. Slack space is useful as it avoids relation extensi

Re: [HACKERS] Request to add options to tools/git_changelog

On Sun, Apr 29, 2012 at 02:06:48PM -0400, Jay Levitt wrote: > Bruce Momjian wrote: > >I am again requesting the addition of options to tools/git_changelog so > >I can more easily produce the release notes. I asked for this during > >9.1 development and it was rejected. I am currently using my own

Re: [HACKERS] extending relations more efficiently

On Wed, May 2, 2012 at 12:26 PM, Alvaro Herrera wrote: > Excerpts from Robert Haas's message of mié may 02 08:14:36 -0400 2012: >> On Wed, May 2, 2012 at 7:16 AM, Jeroen Vermeulen wrote: >> > On 2012-05-01 22:06, Robert Haas wrote: >> >> It might also be interesting to provide a mechanism to pre-

[HACKERS] eqjoinsel_semi still sucks ...

I looked into Maxim Boguk's complaint of bad estimation of antijoin size: http://archives.postgresql.org/pgsql-general/2012-05/msg00033.php I can reproduce what I think the problem is in the regression database. We do okay with this: regression=# explain analyze select * from tenk1 a where not ex

Re: [HACKERS] Have we out-grown Flex?

On 2 May 2012 17:20, Jeff Janes wrote: > For -S -M simple, the time spent planning is 5 times more than the > time spent parsing.  It may be worthwhile to reduce the time spent > parsing, but if the goal is parity with MySQL it probably isn't the > place to start. Could you please share your figu

Re: [HACKERS] extending relations more efficiently

Excerpts from Robert Haas's message of mié may 02 08:14:36 -0400 2012: > On Wed, May 2, 2012 at 7:16 AM, Jeroen Vermeulen wrote: > > On 2012-05-01 22:06, Robert Haas wrote: > >> It might also be interesting to provide a mechanism to pre-extend a > >> relation to a certain number of blocks, though

Re: [HACKERS] smart shutdown at end of transaction (was: Default mode for shutdown)

On Sun, Apr 29, 2012 at 10:19:38AM +0100, Simon Riggs wrote: > Maybe we don't need to do this over multiple releases, but we do need > to give warning of possible incompatibilities. It would be good to see > a specific post on hackers called "Planned Incompatibilities in 9.2", > or collect such thi

Re: [HACKERS] Have we out-grown Flex?

On Tue, May 1, 2012 at 5:53 PM, Peter Geoghegan wrote: > Quite apart from the practical difficulties that we have with Flex > (the fact that the authors are non-responsive and possibly retired, > that annoying compiler warning, and the fact that we are forced to > maintain our own Windows binaries

Re: [HACKERS] clog double-dip in heap_hot_search_buffer

Robert Haas writes: > On Wed, May 2, 2012 at 12:06 PM, Tom Lane wrote: >> Otherwise this seems like a good idea. > Do you think I should apply this to 9.2, or wait until 9.3? We're not at beta yet, and it seems pretty safe/self-contained, so I have no objection to committing now.

Re: [HACKERS] clog double-dip in heap_hot_search_buffer

On Wed, May 2, 2012 at 5:07 PM, Robert Haas wrote: > On Wed, May 2, 2012 at 12:06 PM, Tom Lane wrote: >> Robert Haas writes: >>> +     /* Deleter committed, so tuple is alive if the XID is old enough. */ >>> +     return TransactionIdPrecedes(HeapTupleHeaderGetXmax(tuple), >>> OldestXmin); >> >

Re: [HACKERS] Temporary tables under hot standby

On Wed, May 2, 2012 at 4:14 PM, Bruce Momjian wrote: > I think if implementing global temporary tables only for hot standby > user (#7), it might be of limited usefulness, but the ability to avoid > system table churn (#1) means global temporary tables would have a wide > usefulness, even without

Re: [HACKERS] clog double-dip in heap_hot_search_buffer

On Wed, May 2, 2012 at 12:06 PM, Tom Lane wrote: > Robert Haas writes: >> +     /* Deleter committed, so tuple is alive if the XID is old enough. */ >> +     return TransactionIdPrecedes(HeapTupleHeaderGetXmax(tuple), >> OldestXmin); > > s/alive/dead/ in that comment? Yep, good catch, thanks.

Re: [HACKERS] clog double-dip in heap_hot_search_buffer

Robert Haas writes: > + /* Deleter committed, so tuple is alive if the XID is old enough. */ > + return TransactionIdPrecedes(HeapTupleHeaderGetXmax(tuple), OldestXmin); s/alive/dead/ in that comment? Otherwise this seems like a good idea. regards, tom lane --

Re: [HACKERS] Temporary tables under hot standby

On Wed, May 2, 2012 at 11:39 AM, Michael Nolan wrote: > What is the use case for temporary tables on a hot standby server? Simple... We required a "hot standby" server in order to get improved reliability. But we don't want it to sit there chewing power + money, unused. We want to *use* it to

Re: [HACKERS] Temporary tables under hot standby

What is the use case for temporary tables on a hot standby server? Perhaps this is a noobie question, but it seems to me that a hot standby server's use by* applications* or *users* should be limited to transactions that don't alter the database in any form. However, I can see where temporary tab

[HACKERS] Latch for the WAL writer - further reducing idle wake-ups.

Attached patch latches up the WAL Writer, reducing wake-ups and thus saving electricity in a way that is more-or-less analogous to my work on the BGWriter: http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=6d90eaaa89a007e0d365f49d6436f35d2392cfeb I am hoping this gets into 9.2 . I am

Re: [HACKERS] Temporary tables under hot standby

On Thu, Apr 26, 2012 at 08:56:40AM +0100, Simon Riggs wrote: > A full GTT implementation is not required and the design differed from > that. I don't think "hideously complicated" is accurate, that's just > you're way of saying "and I disagree". Either route is pretty complex > and not much to choo

[HACKERS] clog double-dip in heap_hot_search_buffer

heap_hot_search_buffer() does this: valid = HeapTupleSatisfiesVisibility(heapTuple, snapshot, buffer); If it turns out that the tuple isn't valid (i.e. visible to our scan) and we haven't yet found any live tuples in the current HOT chain, then we check whether it's visible to anyone

Re: [HACKERS] proposal: additional error fields

Tom Lane wrote: > "Kevin Grittner" writes: >> That "F0" class looks suspicious; are those really defined by >> standard or did we encroach on standard naming space with >> PostgreSQL-specific values? > > I think we screwed up on that :-(. So we ought to renumber those > codes anyway. Perhaps u

Re: [HACKERS] proposal: additional error fields

"Kevin Grittner" writes: > That "F0" class looks suspicious; are those really defined by standard or > did we encroach on standard naming space with PostgreSQL-specific > values? I think we screwed up on that :-(. So we ought to renumber those codes anyway. Perhaps use "PF" instead of "F0"?

Re: [HACKERS] proposal: additional error fields

Tom Lane wrote: > My guess is that all the ones defined in the SQL standard are > "expected" errors, more or less by definition, and thus not > interesting according to Peter G's criteria. On a scan through the list, I didn't see any exceptions to that, except for the "F0" class. To restate w

Re: [HACKERS] Patch: add conversion from pg_wchar to multibyte

On Wed, May 2, 2012 at 5:48 PM, Robert Haas wrote: > On Wed, May 2, 2012 at 9:35 AM, Alexander Korotkov > wrote: > > Imagine we've two queries: > > 1) SELECT * FROM tbl WHERE col LIKE '%abcd%'; > > 2) SELECT * FROM tbl WHERE col LIKE '%abcdefghijk%'; > > > > The first query require reading post

Re: [HACKERS] Patch: add conversion from pg_wchar to multibyte

On Wed, May 2, 2012 at 9:35 AM, Alexander Korotkov wrote: >> I was thinking you could perhaps do it just based on the *number* of >> trigrams, not necessarily their frequency. > > Imagine we've two queries: > 1) SELECT * FROM tbl WHERE col LIKE '%abcd%'; > 2) SELECT * FROM tbl WHERE col LIKE '%abc

Re: [HACKERS] Have we out-grown Flex?

On 2 May 2012 04:57, Tom Lane wrote: > FWIW, I think only developers not packagers would really be taking such > a hit.  I assume we'd continue to ship prebuilt lexer output in > tarballs, so there'd seldom be a reason for a packager to need to run > the tool.  Given the extremely slow rate of chu

Re: [HACKERS] Patch: add conversion from pg_wchar to multibyte

On Wed, May 2, 2012 at 4:50 PM, Robert Haas wrote: > On Tue, May 1, 2012 at 6:02 PM, Alexander Korotkov > wrote: > > Right. When number of trigrams is big, it is slow to scan posting list of > > all of them. The solution is this case is to exclude most frequent > trigrams > > from index scan. B

Re: [HACKERS] proposal: additional error fields

Peter Eisentraut writes: > On tis, 2012-05-01 at 20:13 -0400, Tom Lane wrote: >> I don't deny that we probably need to reclassify a few error cases, >> and fix some elogs that should be ereports, before this approach would >> be really workable. My point is that it's *close*, whereas "let's >> in

Re: [HACKERS] Patch: add conversion from pg_wchar to multibyte

On Tue, May 1, 2012 at 6:02 PM, Alexander Korotkov wrote: > Right. When number of trigrams is big, it is slow to scan posting list of > all of them. The solution is this case is to exclude most frequent trigrams > from index scan. But, it require some kind of statistics of trigrams > frequencies

Re: [HACKERS] index-only scans vs. Hot Standby, round two

On Thu, Apr 26, 2012 at 8:03 PM, Robert Haas wrote: > So, as a first step, I've committed a patch that just throws a hard > conflict.  I think we probably want to optimize this further, and I'm > going to work investigate that next.  But it seemed productive to get > this much out of the way first

Re: [HACKERS] extending relations more efficiently

On Wed, May 2, 2012 at 7:16 AM, Jeroen Vermeulen wrote: > On 2012-05-01 22:06, Robert Haas wrote: >> It might also be interesting to provide a mechanism to pre-extend a >> relation to a certain number of blocks, though if we did that we'd >> have to make sure that autovac got the memo not to trunc

Re: [HACKERS] Have we out-grown Flex?

On 2 May 2012 04:24, Robert Haas wrote: > I think Tom's question of whether the parser or lexer is the problem > is something that ought to be investigated.  Personally, I suspect > that our tendency to use lists everywhere, for everything, an artifact > of our proud LISP heritage, may be costing

[HACKERS] How hard would it be to support LIKE in return declaration of generic record function calls ?

Hi Hackers How hard would it be to add support for LIKE syntax, similar to table def in field list declaration for generic record functions What I'dd like to be able to do is to have a generic json_to_record function CREATE OR REPLACE RECORD json_to_record(json) RETURNS RECORD AS $$ ... $$ LANG

Re: [HACKERS] extending relations more efficiently

On 2012-05-01 22:06, Robert Haas wrote: It might also be interesting to provide a mechanism to pre-extend a relation to a certain number of blocks, though if we did that we'd have to make sure that autovac got the memo not to truncate those pages away again. Good point. And just to check befo

Re: [HACKERS] Analyzing foreign tables & memory problems

I wrote: > Noah Misch wrote: >>> During ANALYZE, in analyze.c, functions compute_minimal_stats >>> and compute_scalar_stats, values whose length exceed >>> WIDTH_THRESHOLD (= 1024) are not used for calculating statistics >>> other than that they are counted as "too wide rows" and assumed >>> to be

Re: [HACKERS] JSON in 9.2 - Could we have just one to_json() function instead of two separate versions ?

On Tue, 2012-05-01 at 19:11 -0400, Tom Lane wrote: > Andrew Dunstan writes: > > On Tue, May 1, 2012 at 9:56 AM, Joey Adams > > wrote: > >> No, the RFC says (emphasis mine): > >> > >> A JSON *text* is a serialized object or array. > >> > >> If we let the JSON type correspond to a *value* instead

Re: [HACKERS] JSON in 9.2 - Could we have just one to_json() function instead of two separate versions ?

On Tue, 2012-05-01 at 21:22 -0400, David Johnston wrote: > On May 1, 2012, at 20:41, Hannu Krosing wrote: > > > > Most people don't work in strongly-typed environment, and thus would > > work around such restriction if they need a simple JSON value at the > > other end of the interchange. > > >

Re: [HACKERS] proposal: additional error fields

On tis, 2012-05-01 at 20:13 -0400, Tom Lane wrote: > I don't deny that we probably need to reclassify a few error cases, > and fix some elogs that should be ereports, before this approach would > be really workable. My point is that it's *close*, whereas "let's > invent some new error severities"