On 03/08/2013 10:42 PM, Andrew Dunstan wrote:
On 03/08/2013 04:28 PM, David E. Wheeler wrote:
On Mar 8, 2013, at 1:21 PM, Andrew Dunstan wrote:
Here's what rfc2119 says about that wording:
4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
there may exist valid reaso
On 03/08/2013 11:03 PM, Andrew Dunstan wrote:
On 03/08/2013 04:42 PM, Andrew Dunstan wrote:
So my order of preference for the options would be:
1. Have the JSON type collapse objects so the last instance of a key
wins and is actually stored
2. Throw an error when a JSON type has duplicat
On 03/13/2013 12:40 PM, David E. Wheeler wrote:
On Mar 13, 2013, at 5:17 AM, Robert Haas wrote:
What I think is tricky here is that there's more than one way to
conceptualize what the JSON data type really is. Is it a key-value
store of sorts, or just a way to store text values that meet cert
On 04/08/2013 12:34 PM, Samrat Revagade wrote:
Hello,
We have been trying to figure out possible solutions to the following
problem in streaming replication Consider following scenario:
If master receives commit command, it writes and flushes commit WAL
records to the disk, It also writes a
On 04/10/2013 11:02 PM, Alvaro Herrera wrote:
Peter Eisentraut wrote:
I think the main uses cases mentioned in connection with this idea are
usually in the direction of finer-grained control over what gets dumped
and how. But making pg_dump into a library would not necessarily
address that.
T
On 04/11/2013 01:26 PM, Sameer Thakur wrote:
Hello,
>The only potential use case for this that I can see, would be for
system maintenance and a controlled failover. I agree: that's a major
PITA >when doing DR testing, but I personally don't think this is the
way to fix that particular edge cas
On 04/11/2013 03:52 PM, Ants Aasma wrote:
On Thu, Apr 11, 2013 at 4:25 PM, Hannu Krosing wrote:
The proposed fix - halting all writes of data pages to disk and
to WAL files while waiting ACK from standby - will tremendously
slow down all parallel work on master.
This is not what is being
On 04/11/2013 07:29 PM, Fujii Masao wrote:
On Thu, Apr 11, 2013 at 10:25 PM, Hannu Krosing wrote:
You just shut down the old master and let the standby catch
up (takas a few microseconds ;) ) before you promote it.
After this you can start up the former master with recovery.conf
and it will
On 04/11/2013 12:17 AM, Tom Lane wrote:
Alvaro Herrera writes:
Hannu Krosing wrote:
Natural solution to this seems to move most of pg_dump functionality
into backend as functions, so we have pg_dump_xxx() for everything
we want to dump plus a topological sort function for getting the
objects
On 04/14/2013 05:56 PM, Fujii Masao wrote:
On Fri, Apr 12, 2013 at 7:57 PM, Andres Freund wrote:
On 2013-04-12 02:29:01 +0900, Fujii Masao wrote:
On Thu, Apr 11, 2013 at 10:25 PM, Hannu Krosing wrote:
You just shut down the old master and let the standby catch
up (takas a few microseconds
On 04/15/2013 06:04 PM, Simon Riggs wrote:
On 15 April 2013 16:55, Tom Lane wrote:
Simon Riggs writes:
On 15 April 2013 16:24, David Fetter wrote:
Do you have numbers on this, or ways to gather same? In other words,
how do we know what resources (time, CPU cycles, disk seeks, etc.) are
bei
On 05/14/2013 10:05 AM, Simon Riggs wrote:
> I'm proposing this now as a possible GSoC project:
>
> In 1-byte character encodings (i.e. not UTF-8), SUBSTR() is optimised
> to allow seeking straight to the exact slice when retrieving a large
> toasted value. This reduces I/O considerably when you ha
On 05/13/2013 07:10 PM, Robert Haas wrote:
> On Mon, May 13, 2013 at 10:57 AM, Tom Lane wrote:
>> This approach seems to me to be likely to guarantee that the startup
>> overhead for any parallel sort is so large that only fantastically
>> enormous sorts will come out ahead.
>>
>> I think you need
On 05/15/2013 07:30 AM, Tom Lane wrote:
> Hannu Krosing writes:
>> Has anybody looked into making syscache MVCC compliant ?
> This is the wrong statement of the question.
>
> The right statement is "how would you like backend A to be updating
> table T in complianc
ists | all
?
Cheers,
Hannu Krosing
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 09/25/2012 04:26 AM, Andrew Dunstan wrote:
On 09/24/2012 09:37 PM, Peter Eisentraut wrote:
On Mon, 2012-09-24 at 18:59 -0400, Andrew Dunstan wrote:
This rather overdue mail arises out the developer's meeting back in
May, where we discussed an item I raised suggesting an Oid registry.
The i
On 09/25/2012 12:13 PM, Heikki Linnakangas wrote:
On 25.09.2012 12:19, Hitoshi Harada wrote:
On Tue, Sep 25, 2012 at 1:06 AM, Simon Riggs
wrote:
On 24 September 2012 21:26, Andrew Dunstan wrote:
Well, an obvious case is how record_to_json handles fields. If it
knows
nothing about the type a
On 09/26/2012 12:06 AM, Peter Eisentraut wrote:
On 9/25/12 5:58 PM, Tom Lane wrote:
Yes ... but I really don't want to go down the path of treating those as
new type properties; it doesn't scale. (And please don't tell me that
JSON is the last word in container types and there will never be
req
On 09/26/2012 02:48 AM, Andrew Dunstan wrote:
On 09/25/2012 08:35 PM, Peter Eisentraut wrote:
On Tue, 2012-09-25 at 18:22 -0400, Tom Lane wrote:
Actually, after reading another message you sent, I thought you were
going to respond that your proposed transforms feature would cover it.
I had th
On 09/26/2012 06:46 PM, Tom Lane wrote:
Andrew Dunstan writes:
Drawing together various discussions both here and elsewhere (e.g. the
PostgresOpen hallway track) I propose to work on the following:
1. make datum_to_json() honor a type's cast to json if it exists. The
fallback is to use the type
On 09/26/2012 01:02 AM, m...@rpzdesign.com wrote:
John:
Who has the money for oracle RAC or funding arrogant bastard Oracle
CEO Ellison to purchase another island?
Postgres needs CHEAP, easy to setup, self healing,
master-master-master-master and it needs it yesterday.
I was able to patch
On 09/27/2012 09:18 PM, Andrew Dunstan wrote:
On 09/27/2012 10:36 AM, Tom Lane wrote:
Andrew Dunstan writes:
On 09/27/2012 09:22 AM, Robert Haas wrote:
Maybe I am being too pedantic about this and there is a way to make it
all work nicely, but it sure feels like using the casting machinery
h
On 09/28/2012 12:42 AM, Andrew Dunstan wrote:
On 09/27/2012 06:58 PM, Hannu Krosing wrote:
On 09/27/2012 09:18 PM, Andrew Dunstan wrote:
On 09/27/2012 10:36 AM, Tom Lane wrote:
Andrew Dunstan writes:
On 09/27/2012 09:22 AM, Robert Haas wrote:
Maybe I am being too pedantic about this and
On 09/26/2012 06:46 PM, Tom Lane wrote:
Andrew Dunstan writes:
Drawing together various discussions both here and elsewhere (e.g. the
PostgresOpen hallway track) I propose to work on the following:
1. make datum_to_json() honor a type's cast to json if it exists. The
fallback is to use the type
On 09/29/2012 05:40 PM, Andrew Dunstan wrote:
I am not opposed to making a new type, but I really don't think that
means we need to do nothing for the existing data type. The suggested
SERIALIZATION mechanism seems to be fairly intrusive and heavy handed,
as opposed to the very lightweight
On 09/29/2012 10:29 PM, Andrew Dunstan wrote:
On 09/29/2012 05:01 PM, Hannu Krosing wrote:
On 09/29/2012 05:40 PM, Andrew Dunstan wrote:
I still think Tom's suggestion is the best and simplest way to do that.
which Toms suggestion you mean here ?
The 3. mentioned above was for m
urity concern this could be alleviated by only
allowing it in the untrusted languages.
Hannu Krosing
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 10/10/2012 02:58 PM, Tom Lane wrote:
Hannu Krosing writes:
Is the lack of support of cstring in PLs just laziness/ovelook or is
there a good
reason why PL languages do not support cstring type arguments and return
values ?
In general I don't think we should encourage the use of cstri
On 10/10/2012 03:46 PM, Tom Lane wrote:
Hannu Krosing writes:
On 10/10/2012 02:58 PM, Tom Lane wrote:
It's hard for me to see how you'd make the above work without
circularity, ie the PL manager would end up recursively calling itself
trying to construct or deconstruct the val
On 10/10/2012 04:34 PM, Tom Lane wrote:
Hannu Krosing writes:
One way would be to check that we are in an any --> cstring
function - perhaps just by setting some static flag et entry and resetting
it at exit - and pass the original byte representation as "bytes" (or
string for py
On 10/11/2012 04:31 AM, Tom Lane wrote:
Greg Stark writes:
On Thu, Oct 11, 2012 at 2:40 AM, Tom Lane wrote:
Isn't there an even more serious problem, namely that this assumes
*all* transactions are serializable? What happens when they aren't?
Or even just that the effective commit order is n
On 10/11/2012 03:10 AM, Robert Haas wrote:
On Wed, Oct 10, 2012 at 7:02 PM, Peter Geoghegan wrote:
The purpose of ApplyCache/transaction reassembly is to reassemble
interlaced records, and organise them by XID, so that the consumer
client code sees only streams (well, lists) of records split by
On 10/12/2012 05:47 AM, David Johnston wrote:
-Original Message-
From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
ow...@postgresql.org] On Behalf Of Andrew Dunstan
Sent: Thursday, October 11, 2012 8:52 PM
To: Daniel Farina
Cc: Joshua D. Drake; Josh Berkus; Simon Riggs;
pgs
ur of hardcoded changes that catch users.
This would be a documented change and one that is alterable, should
the user wish.
So your comments don't apply.
Nah! You already surprised Andrew by proposing to remove rules ;)
--------
Hannu Krosing
--
Sent via pgsql-hackers mailing
On 10/12/2012 06:59 PM, Josh Berkus wrote:
I don't think you're listening, none of those things are problems and
so not user hostile.
Having an upgrade fail for mysterious reasons with a cryptic error
message the user doesn't understand isn't user-hostile? Wow, you must
have a very understandin
t things do without explaining why that might be
useful. That's leaves users faced with a decision between trying
similar-sounding features like rules and triggers and they might pick
the wrong one. The Postgres manual is better than most in this respect
but this is one area where it migh
On 10/12/2012 11:05 PM, Christopher Browne wrote:
On Fri, Oct 12, 2012 at 3:04 PM, Robert Haas wrote:
On Thu, Oct 11, 2012 at 3:22 PM, Simon Riggs wrote:
So we just need a function called pg_if_table_exists(table, SQL) which
wraps a test in a subtransaction.
And you write
SELECT pg_if_table
On 10/15/2012 04:34 PM, Greg Stark wrote:
On Mon, Oct 15, 2012 at 3:26 PM, Robert Haas wrote:
To be perfectly frank, I think that's exactly where we ought to be
going. Oracle and Microsoft both did it, so why are we convinced it's
a bad idea? One of the huge problems with PL/pgsql is that eve
On 10/15/2012 12:41 PM, Greg Stark wrote:
On Mon, Oct 15, 2012 at 8:00 AM, Simon Riggs wrote:
Please can anyone show me the SQL for a rule that cannot be written as
a view or a trigger? I do not believe such a thing exists and I will
provide free beer to the first person that can prove me wrong
On 10/11/2012 01:42 PM, Andres Freund wrote:
On Thursday, October 11, 2012 09:15:47 AM Heikki Linnakangas wrote:
...
If the only meaningful advantage is reducing the amount of WAL written,
I can't help thinking that we should just try to address that in the
existing solutions, even if it seems "e
On 10/15/2012 04:54 AM, Robert Haas wrote:
On Thu, Oct 11, 2012 at 3:15 AM, Heikki Linnakangas
wrote:
IMHO that's a good thing, and I'd hope this new logical replication to live
outside core as well, as much as possible. But whether or not something is
in core is just a political decision, not
On 10/15/2012 08:44 PM, Andres Freund wrote:
On Monday, October 15, 2012 08:38:07 PM Hannu Krosing wrote:
On 10/11/2012 01:42 PM, Andres Freund wrote:
On Thursday, October 11, 2012 09:15:47 AM Heikki Linnakangas wrote:
...
If the only meaningful advantage is reducing the amount of WAL written
On 10/15/2012 04:54 AM, Robert Haas wrote:
PS. I'd love to see a basic Slony plugin for this, for example, to see how
>much extra code on top of the posted patches you need to write in a plugin
>like that to make it functional. I'm worried that it's a lot..
I agree. I would go so far as to say
replacement for implementing full Londiste / skytools
functionality
but would also become a very strong player to be used as persistent
basis for
message queueing solutions like ActiveMQ, StorMQ, any Advanced Message
Queuing Protocol (AMQP) and so on.
comments ?
Hannu Krosing
--
Sent vi
On 10/16/2012 11:18 AM, Simon Riggs wrote:
On 16 October 2012 09:56, Hannu Krosing wrote:
Hallo postgresql and replication hackers
This mail is an additional RFC which proposes a simple way to extend the
new logical replication feature so it can cover most usages of
skytools/pgq/londiste
On 10/16/2012 11:29 AM, Hannu Krosing wrote:
On 10/16/2012 11:18 AM, Simon Riggs wrote:
On 16 October 2012 09:56, Hannu Krosing wrote:
Hallo postgresql and replication hackers
This mail is an additional RFC which proposes a simple way to extend
the
new logical replication feature so it can
quot; needs a set of interface
functions to extract the events and also to keep track of the processed
events. As there is no general consensus what these shoul be (like if
processing same event twice is allowed) this part is left for specific
queue consumer implementations.
On 10/17/2012 11:31 AM, Dimitri Fontaine wrote:
Peter Geoghegan writes:
Clearly deprecating rules implies some loss of functionality - there
is no exact, drop-in equivalent to something that magically rewrites
SQL that isn't equally baroque and problematic.
Maybe we can upgrade STATEMENT trigg
On 10/18/2012 07:33 PM, Josh Berkus wrote:
Simon,
It's hard to work out how to reply to this because its just so off
base. I don't agree with the restrictions you think you see at all,
saying it politely rather than giving a one word answer.
You have inside knowledge of Hannu's design.
Actua
On 10/18/2012 08:36 PM, Claudio Freire wrote:
The CREATE QUEUE command, in fact, could be creating
such a channel. The channel itself won't be WAL-only, just
the messages going through it. This (I think) would solve locking issues.
Hmm. Maybe we should think of implementing this as REMOTE TABL
On 10/19/2012 04:26 AM, Ants Aasma wrote:
On Thu, Oct 18, 2012 at 10:03 PM, Hannu Krosing wrote:
Hmm. Maybe we should think of implementing this as REMOTE TABLE, that
is a table which gets no real data stored locally but all insert got through
WAL
and are replayed as real inserts on slave side
On 10/18/2012 09:18 PM, Christopher Browne wrote:
On Thu, Oct 18, 2012 at 2:56 PM, Hannu Krosing wrote:
* works as table on INSERTS up to inserting logical WAL record describing
the
insert but no data is inserted locally.
with all things that follow from the local table having no data
On 10/23/2012 01:31 AM, Greg Stark wrote:
On Wed, Oct 17, 2012 at 7:48 PM, Christopher Browne wrote:
Well, replication is arguably a relevant case.
For Slony, the origin/master node never cares about logged changes - that
data is only processed on replicas. Now, that's certainly a little weas
On 10/23/2012 04:13 PM, Tom Lane wrote:
[ hadn't been following this thread, sorry ]
Hannu Krosing writes:
My RFC was for a proposal to skip writing the unneeded info in local
tables and put it _only_ in WAL.
This concept seems fundamentally broken. What will happen if the master
cr
On 10/23/2012 06:47 PM, Robert Haas wrote:
On Wed, Oct 17, 2012 at 4:25 PM, Josh Berkus wrote:
...
3. Double-down on #2 in a multithreaded environment.
For an application-level queue, the base functionality is:
ADD ITEM
READ NEXT (#) ITEM(S)
LOCK ITEM
DELETE ITEM
More sophisticated an usefu
This is how PostgreSQL currently works -
test=# select 'NaN'::float = 'NaN'::float as must_be_false;
must_be_false
--
t
(1 row)
I think that PostgreSQL's behaviour of comparing two
NaN-s as equal is wrong and Iwe should follow the IEEE 754 spec here
As per IEEE 754 a NaN behaves simil
LL IS NOT DISTINCT FROM NULL as must_be_true;
must_be_true
--
t
(1 row)
I guess making the NaN comparison IEEE compliant could introduce
some problems with indexes, so I propose that index operators would
treat NaNs like NULLs
Hannu
Il giorno 28/ott/2012, alle ore 20:43, Hannu Kr
On 10/28/2012 11:21 AM, Thomas Munro wrote:
On 28 October 2012 09:43, Hannu Krosing wrote:
This is how PostgreSQL currently works -
test=# select 'NaN'::float = 'NaN'::float as must_be_false;
must_be_false
--
t
(1 row)
I think that PostgreSQL's behaviour
Hi
Is there a way to test for a variable being unassigned in pl/pgsql ?
I'm writing an audit trigger where I'd like to save full before and
after images into audit log and I really do not like to do
IF TG_OP IN ('INSERT', 'UPDATE') ...
I'd like rather better if i could just write
IF NEW IS AS
On 10/29/2012 05:36 PM, Merlin Moncure wrote:
On Mon, Oct 29, 2012 at 11:26 AM, Pavel Stehule wrote:
Hello
2012/10/29 Hannu Krosing :
Hi
Is there a way to test for a variable being unassigned in pl/pgsql ?
I'm writing an audit trigger where I'd like to save full before and
af
On 10/30/2012 01:37 PM, crocket wrote:
MySQL permits a connection to access multiple databases.
But Postgresql restricts a connection to one database.
I think postgresql database connection is somewhat limited.
Is it an old and decrepit design? or does it deserve some appreciations?
It's an old
On 10/29/2012 03:14 PM, Amit Kapila wrote:
On Monday, October 29, 2012 7:11 PM Chris Corbyn
> What's the use case of this? It sounds like it will just create a
maintenance nightmare where some stuff you expect to lookup in in
postgresql.conf is actually hiding in the .auto file. Assuming only
On 11/02/2012 09:46 PM, Daniel Farina wrote:
The bar for "reliable" non-volatile storage for me are things like
Amazon's S3, and I think a lot of that has to do with the otherwise
relatively impoverished semantics it has, so I think this reliability
profile will be or has been duplicated elsewher
On 11/08/2012 11:40 PM, Simon Riggs wrote:
On 8 November 2012 20:36, Jeff Janes wrote:
It does not seem outrageous to me that there would be real-world
conditions in which invalidations would be sent more than once a
minute over prolonged periods, so this total starvation seems like a
bug.
Ye
On 11/08/2012 08:51 PM, Simon Riggs wrote:
On 8 November 2012 17:07, Robert Haas wrote:
On Wed, Nov 7, 2012 at 10:34 AM, Simon Riggs wrote:
For 9.2 we discussed having COPY setting tuples as frozen. Various
details apply.
Earlier threads:
"RFC: Making TRUNCATE more "MVCC-safe"
"COPY wit
On 11/09/2012 09:34 AM, Simon Riggs wrote:
On 8 November 2012 23:20, Hannu Krosing wrote:
On 11/08/2012 08:51 PM, Simon Riggs wrote:
On 8 November 2012 17:07, Robert Haas wrote:
On Wed, Nov 7, 2012 at 10:34 AM, Simon Riggs
wrote:
For 9.2 we discussed having COPY setting tuples as frozen
On 11/15/2012 09:48 AM, Craig Ringer wrote:
If you want to prevent TRUNCATE, deny the privilege or add a trigger
that aborts the command.
You can abort the transaction but not skip action as currently it is only
possible to skip in ROW level triggers.
So I'd modify this request to allow BEFORE
unction
select utf_test2();
still enters wrong data to the table
So SPI interface should also be fixed, either from perl side, or maybe
from inside SPI ?
--
Hannu Krosing http://www.2ndQuadrant.com
PostgreSQL Scalability and Availability
Services, Consulting and Trai
On Mon, 2010-03-08 at 21:52 -0500, Andrew Dunstan wrote:
>
> Tom Lane wrote:
> > Hannu Krosing writes:
> >
> >> So SPI interface should also be fixed, either from perl side, or maybe
> >> from inside SPI ?
> >>
> >
> > SPI has eve
int bits, ...)
BTW, is the stats-collection reliable enough for this or is it still
possible to lose some changes if we did this together with updating info
for pg_stat_user_tables/pg_statio_user_tables ?
--
Hannu Krosing http://www.2ndQuadrant.com
PostgreSQL Scalability and Availability
can you trust
> any application *running* under that OS to do it?
>
> > Is this route worthwhile?
>
> I'm not seeing it, but I could be missing something. Can you
> describe a use case where this would be beneficial?
>
> -Kevin
>
--
Hannu Krosing
t; supplied dump. This is more complicated but maybe more useful for a
> broader audience?
Yes, I see the main value in of this for pg_dump backups, as physical
files already have this in terms of file ctime/mtime/atime
>
> Side question: is it impractical to backup via pg_dump a hot st
ge
time _after_ the backup anyway, it is easy to wait a few secs to be
sure.
> Florian's point about clock changes is also very relevant. Since
> Postgres has the capability to give a better answer about what is in the
> file, it would be best to use that.
>
> -- m. tharp
>
-
after that, which is also slow on large tables)
This would actually be a good sample case for tracking "latest dml",
except that in this particular corner case you can arrange for this
yourself.
--
Hannu Krosing http://www.2ndQuadrant.com
PostgreSQL Scalability and Availability
Service
On Tue, 2012-01-31 at 12:58 -0500, Andrew Dunstan wrote:
>
> On 01/30/2012 10:37 AM, Andrew Dunstan wrote:
> >
> >
> >> Aside: is query_to_json really necessary? It seems rather ugly and
> >> easily avoidable using row_to_json.
> >>
> >
> > I started with this, again by analogy with query_to_xml()
On Mon, 2012-04-16 at 10:10 -0400, Andrew Dunstan wrote:
>
> On 04/16/2012 09:34 AM, Hannu Krosing wrote:
> >> based on Abhijit's feeling and some discussion offline, the consensus
> >> seems to be to remove query_to_json.
> > The only comment I have here is
On Sat, 2012-04-28 at 09:36 +0100, Simon Riggs wrote:
> On Fri, Apr 27, 2012 at 11:50 PM, Christopher Browne
> wrote:
> > On Fri, Apr 27, 2012 at 4:11 AM, Simon Riggs wrote:
> >> What I'm hoping to do is to build a basic prototype of logical
> >> replication using WAL translation, so we can insp
On Sat, 2012-04-28 at 21:40 +0200, Hannu Krosing wrote:
> On Sat, 2012-04-28 at 09:36 +0100, Simon Riggs wrote:
> > On Fri, Apr 27, 2012 at 11:50 PM, Christopher Browne
> > wrote:
> > > On Fri, Apr 27, 2012 at 4:11 AM, Simon Riggs
> > > wrote:
> > >&
On Sun, 2012-04-29 at 12:03 +0100, Simon Riggs wrote:
> On Sat, Apr 28, 2012 at 8:40 PM, Hannu Krosing wrote:
>
> > As to what LCRs should contain, it will probably be locical equivalents
> > of INSERT, UPDATE ... LIMIT 1, DELETE ... LIMIT 1, TRUNCATE and all DDL.
>
> Ye
l.
An optionally sync mode similar to current sync WAL replication could be
configured. I hope this would run mostly in parallel with local WAL
generation so not much extra wall-clock time would be wasted.
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreS
2 rows)
and even
hannu=# select row_to_json(s) from (select 1::int as i, (select z
from(select 2::int as j, 'x'::text as x)z) as t union select 2,null)s;
row_to_json
-
{"i":1,"t":{"j":2,"x":"x&q
On Tue, 2012-05-01 at 08:18 -0500, Merlin Moncure wrote:
> On Tue, May 1, 2012 at 7:02 AM, Hannu Krosing wrote:
> > Hi hackers
> >
> > After playing around with array_to_json() and row_to_json() functions a
> > bit it I have a question - why do we eve
On Tue, 2012-05-01 at 11:49 -0400, Joey Adams wrote:
> On Tue, May 1, 2012 at 8:02 AM, Hannu Krosing wrote:
> > Hi hackers
> >
> > After playing around with array_to_json() and row_to_json() functions a
> > bit it I have a question - why do we even have 2 variants
but not always "JSON
text" which indeed has to be array or object .
> > If anything, we should adjust the JSON input routines
> > to disallow anything else, rather than start to output what is not valid
> > JSON.
Nah, I'd like us to accept what other JSON p
another type for json_value.
And it is entirely possible that somebody does want to do what merlin
described recently, that is get a rowset of "json" values from the
client and wrap them in '[' and ']' on way out, it wuld be shame to
restrict his json ar
On Tue, 2012-05-01 at 09:22 -0700, Andrew Dunstan wrote:
>
>
> On Tue, May 1, 2012 at 9:05 AM, Merlin Moncure
> wrote:
> On Tue, May 1, 2012 at 10:49 AM, Joey Adams
> wrote:
> > On Tue, May 1, 2012 at 8:02 AM, Hannu Krosing
> wro
On Tue, 2012-05-01 at 18:35 -0400, David Johnston wrote:
> > -Original Message-
> > From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
> > ow...@postgresql.org] On Behalf Of Hannu Krosing
> > Sent: Tuesday, May 01, 2012 5:29 PM
> >
> > The
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
> &
lement, indent int)
with the behavior that if indent is NULL or negative integer no
pretty-printing is done, if it is 0 printing starts at left margin and
if it is a positive integer then this number of spaces is added to the
left for each row (except the first one) of the json representation.
And
json_to_record(jrec json)
as (id int, data2 test, tstamp timestamp);
INSERT 0 1
PS.
As a pie-in-the-sky wish I'd prefer of course even simpler syntax of
insert into test2 json_to_record(jrec json);
or at least
insert into test2 json_to_record(jrec json)::test2;
On Wed, 2012-05-02 at 14:32 -0500, Merlin Moncure wrote:
> 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 l
On Wed, 2012-05-02 at 12:06 -0700, Andrew Dunstan wrote:
>
>
> On Wed, May 2, 2012 at 2:29 AM, Hannu Krosing
> wrote:
>
>
>
> I don't object to row_to_json() and array_to_json() functions
> being
> th
On Thu, 2012-05-03 at 00:58 -0500, Jim Nasby wrote:
> 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 UPD
On Fri, 2012-05-04 at 13:43 -0400, Robert Haas wrote:
> On Fri, May 4, 2012 at 12:56 PM, Tom Lane wrote:
> > Andrew Dunstan writes:
> >> Yeah, what I've been thinking about in conjunction with similar problems
> >> is some sort of type registry, so that we could code for non-builtin
> >> types in
On Fri, 2012-05-04 at 09:52 -0400, Tom Lane wrote:
> Hannu Krosing writes:
> > On Wed, 2012-05-02 at 12:06 -0700, Andrew Dunstan wrote:
> >> So given that do we do anything about this now, or wait till 9.3?
>
> > I'd like the json support in 9.2 updated as follo
On Fri, 2012-05-04 at 15:59 -0400, Robert Haas wrote:
> On Fri, May 4, 2012 at 3:49 PM, Hannu Krosing wrote:
> > On Fri, 2012-05-04 at 09:52 -0400, Tom Lane wrote:
> >> Hannu Krosing writes:
> >> > On Wed, 2012-05-02 at 12:06 -0700, Andrew Dunstan wrote:
> >
On Fri, 2012-05-04 at 15:59 -0400, Robert Haas wrote:
> On Fri, May 4, 2012 at 3:49 PM, Hannu Krosing wrote:
> > On Fri, 2012-05-04 at 09:52 -0400, Tom Lane wrote:
> >> Hannu Krosing writes:
> >> > On Wed, 2012-05-02 at 12:06 -0700, Andrew Dunstan wrote:
> >
On Fri, 2012-05-04 at 16:12 -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Fri, May 4, 2012 at 3:49 PM, Hannu Krosing wrote:
> >> Can we at least have the xxx_to_json() functions try cast to json first
> >> and fall back to text if the cast fails.
>
>
So casting first then fall back to _quoted_ text is wrong only for those
types which have a very ugly text representation :)
--
---
Hannu Krosing
PostgreSQL Unlimited Scalability and Performance Consultant
2ndQuadrant Nordic
PG Admin Book: http://www.2ndQuadrant.com/books/
--
Sent v
then discuss using for update cursors further down.
--
---
Hannu Krosing
PostgreSQL Unlimited Scalability and Performance Consultant
2ndQuadrant Nordic
PG Admin Book: http://www.2ndQuadrant.com/books/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
201 - 300 of 1838 matches
Mail list logo
