Hi,
I'm seeing somewhat confusing results here with 9.6.8, and cannot find
the answer in the docs or google.
I'm returning JSON array (or any array, it does not make a difference)
from my plpgsql function like this:
OUT retcode int,
OUT result json)
. . .
result := json_agg(_) FR
On Mon, May 21, 2018 at 10:45:27AM -0400, Tom Lane wrote:
> OP could do something like
>
> declare r record;
> ...
> select json_agg(_) as j, count(*) as c INTO r FROM (
> SELECT foo, bar, baz ...
> FROM t1, t2, t3 WHERE ...) AS _;
>
> This would be slightly more expensive
On Mon, May 21, 2018 at 12:20:52PM -0400, Tom Lane wrote:
> Alexey Dokuchaev writes:
> > On Mon, May 21, 2018 at 10:45:27AM -0400, Tom Lane wrote:
> >> OP could do something like
> >>select json_agg(_) as j, count(*) as c INTO r FROM (
>
> > Thanks, I&#x
On Mon, May 21, 2018 at 12:54:56PM -0400, Tom Lane wrote:
> Alexey Dokuchaev writes:
> > Quick reality check question: are count(*) vs. count(_) equivalent
> > above?
>
> Only if _ is guaranteed non-null ... which, as a rowtype result, it
> probably is. But I'd use
Hi there,
I've decided to run some tests to see how my tables' ids would survive
when their yielding sequences would start hitting their MAXVALUE's, by
doing some "SELECT setval('foo_id_seq', ~maxbigint)". As I don't like
to hardcode numbers (esp. huge numbers, because sequences are always[*]
big
On Fri, Jun 08, 2018 at 10:30:45AM -0700, Adrian Klaver wrote:
> On 06/08/2018 10:23 AM, Alexey Dokuchaev wrote:
> >I've decided to run some tests to see how my tables' ids would survive
> >when their yielding sequences would start hitting their MAXVALUE's, b
On Sat, Jun 09, 2018 at 07:20:17AM -0700, Adrian Klaver wrote:
> On 06/09/2018 05:24 AM, Alexey Dokuchaev wrote:
> >OK, but what about highly volatile tables for come-and-go type of things?
> >Think of a session pool, or task queue. I want to use NO CYCLE for this
> >kind
Hi there,
I have a table with several UNIQUE and CHECK constraints. One of these
UNIQUE constraints actually *can* be violated -- not on the table level,
of course, but on the application level -- meaning, if the entry with
particular foo_key is already in there, do not throw an exception, just
s
On Mon, Jun 11, 2018 at 05:10:33PM +0700, Alexey Dokuchaev wrote:
> The usual approach ("EXCEPTION WHEN unique_violation THEN ... END") does
> not really cut it because I want to catch unique_violation only when it
> happens on "foo_key", and still rightfully complain
On Mon, Jun 11, 2018 at 12:30:13PM +0200, Thomas Kellerer wrote:
> Alexey Dokuchaev schrieb am 11.06.2018 um 12:10:
> > I have a table with several UNIQUE and CHECK constraints. One of these
> > UNIQUE constraints actually *can* be violated -- not on the table level,
> >
On Mon, Jun 11, 2018 at 01:26:16PM +0200, Thomas Kellerer wrote:
> If that functionality is an important part of your code, you should
> consider upgrading to 10 (or 9.6 if your are really conservative)
> rather sooner than later.
Oh well, fair enough. As much as I'd love to stick to the lowest
s
11 matches
Mail list logo
