Hi
2015-08-06 10:37 GMT+02:00 Pavel Stehule :
> Hi,
>
> Psql based implementation needs new infrastructure (more than few lines)
>
> Missing:
>
> * binary mode support
> * parametrized query support,
>
> I am not against, but both points I proposed, and both was
> 0003 is the most controversial. It removes the ability to pass message
> as keyword argument. My reasoning was that keyword arguments are
> usually optional and configure extra aspects of the function call
> while message is required and fundamental so therefore it should be
> positional. If you
Hi
2016-02-29 17:53 GMT+01:00 Pavel Stehule :
>
>
>
>> 0003 is the most controversial. It removes the ability to pass message
>> as keyword argument. My reasoning was that keyword arguments are
>> usually optional and configure extra aspects of the function call
>&
Hi
2016-02-29 2:40 GMT+01:00 Joe Conway :
> On 01/07/2016 09:08 AM, Joe Conway wrote:
> > On 01/06/2016 10:36 AM, Tom Lane wrote:
> >> I think a design that was actually somewhat robust would require two
> >> hooks, one at check_role and one at assign_role, wherein the first one
> >> would do any
Hi
I don't understand how is possible to get more rows from Sort node than in
nested seq scan?
http://explain.depesz.com/s/568O
Sec scan returns 1.6M rows, Sort returns 2.7M rows
Regards
Pavel
2016-03-01 15:45 GMT+01:00 Tom Lane :
> Pavel Stehule writes:
> > I don't understand how is possible to get more rows from Sort node than
> in
> > nested seq scan?
>
> The "extra" rows are re-fetches triggered by mark/restore requests from
> the pare
2016-03-01 16:52 GMT+01:00 Joe Conway :
> On 03/01/2016 02:09 AM, Pavel Stehule wrote:
> > 2016-02-29 2:40 GMT+01:00 Joe Conway > <mailto:m...@joeconway.com>>:
> >
> > On 01/07/2016 09:08 AM, Joe Conway wrote:
> > > On 01/06/2016 10:36 AM, Tom La
2016-03-01 17:00 GMT+01:00 Robert Haas :
> On Tue, Mar 1, 2016 at 10:52 AM, Tom Lane wrote:
> > Aleksander Alekseev writes:
> >> There are applications that create and delete a lot of temporary
> >> tables. Currently PostgreSQL doesn't handle such a use case well.
> >
> > True.
> >
> >> Fast tem
2016-03-01 20:17 GMT+01:00 Jim Nasby :
> On 3/1/16 10:05 AM, Atri Sharma wrote:
>
>> Fair point, that means inventing a whole new OID generation structure..
>>
>
> Generation is just the tip of the iceberg. You still need the equivalent
> to foreign keys (ie: pg_depend). While you would never have
Hi
2016-03-01 18:48 GMT+01:00 Catalin Iacob :
> On 3/1/16, Pavel Stehule wrote:
> >> I though about it before and I prefer variant with possibility to enter
> >> message as keyword parameter.
>
> That's also ok, but indeed with a check that it's not spec
Hi
2016-02-24 22:18 GMT+01:00 Peter Eisentraut :
> On 1/18/16 4:21 PM, Robert Haas wrote:
> > One idea that occurs to me is: If you can DECLARE BAR FOO%TYPE, but
> > then you want to make BAR an array of that type rather than a scalar,
> > why not write that as DECLARE BAR FOO%TYPE[]? That seems
Hi
We have not autocomplete for casting introduced by symbol "::". A
implementation should not be hard.
Regards
Pavel
Hi
2016-02-24 22:18 GMT+01:00 Peter Eisentraut :
> On 1/18/16 4:21 PM, Robert Haas wrote:
> > One idea that occurs to me is: If you can DECLARE BAR FOO%TYPE, but
> > then you want to make BAR an array of that type rather than a scalar,
> > why not write that as DECLARE BAR FOO%TYPE[]? That seems
Hi
2016-03-03 0:27 GMT+01:00 Jim Nasby :
> On 3/2/16 3:52 PM, Pavel Stehule wrote:
>
>> Right, and it's arguably dubious that that doesn't already work.
>> Unfortunately, these % things are just random plpgsql parser hacks,
>> not
>> real types
2016-03-03 12:06 GMT+01:00 Kyotaro HORIGUCHI <
horiguchi.kyot...@lab.ntt.co.jp>:
> Hello, I considered on this,
>
> At Thu, 3 Mar 2016 10:05:06 +0100, Pavel Stehule
> wrote in <
> cafj8prdz456okbpv9jdj_vcgtwprqxyu1kqp6z_eu_wgnvs...@mail.gmail.com>
> > We h
Hi
2016-03-01 22:23 GMT+01:00 Jim Nasby :
> On 2/29/16 10:01 PM, Tom Lane wrote:
>
>> Jim Nasby writes:
>>
>>> On 2/28/16 5:50 PM, Jim Nasby wrote:
>>>
Per discussion in [1], this patch improves error reporting in pltcl.
>>>
>> I forgot to mention that this work is sponsored by Flight
Hi
I am testing behave, and some results looks strange
postgres=# \sf foo
CREATE OR REPLACE FUNCTION public.foo()
RETURNS void
LANGUAGE plpgsql
AS $function$
begin
raise exception sqlstate 'ZZ666' using message='hello, world',
detail='hello, my world', hint = 'dont afraid';
end
$function$
po
2016-03-04 5:29 GMT+01:00 Kyotaro HORIGUCHI :
> At Thu, 3 Mar 2016 12:15:13 +0100, Pavel Stehule
> wrote in <
> cafj8prdb2ppeslxnwndxmhvts9vl0nmeanudv_hps9wzywx...@mail.gmail.com>
> pavel.stehule> 2016-03-03 12:06 GMT+01:00 Kyotaro HORIGUCHI <
> > the requireme
2016-03-04 3:13 GMT+01:00 Corey Huinker :
> On Sat, Feb 27, 2016 at 2:26 AM, Pavel Stehule
> wrote:
>
>> Hi
>>
>> 2015-08-06 10:37 GMT+02:00 Pavel Stehule :
>>
>>> Hi,
>>>
>>> Psql based implementation needs new infrastructure (more th
2016-03-04 15:54 GMT+01:00 Daniel Verite :
> Corey Huinker wrote:
>
> > So, for me, RAW is the right solution, or at least *a* right solution.
>
> Questions on how to extract from a bytea column come up on a regular
> basis, as in [1] [2] [3], or [4] a few days ago, and so far the answers
2016-03-05 21:49 GMT+01:00 Joe Conway :
> On 03/01/2016 08:18 AM, Pavel Stehule wrote:
> > 2016-03-01 16:52 GMT+01:00 Joe Conway:
> > On 03/01/2016 02:09 AM, Pavel Stehule wrote:
> > > > On 01/06/2016 10:36 AM, Tom Lane wrote:
> > > &
2016-03-04 18:06 GMT+01:00 Pavel Stehule :
>
>
> 2016-03-04 15:54 GMT+01:00 Daniel Verite :
>
>> Corey Huinker wrote:
>>
>> > So, for me, RAW is the right solution, or at least *a* right solution.
>>
>> Questions on how to extract from a byte
2016-03-10 15:34 GMT+01:00 Teodor Sigaev :
> select
>>
>> parse_ident(E'X\rXX');
>>
>>
>> I am sending updated patch - I used json function for correct escaping -
>> the
>> escaping behave is same.
>>
>
> Hmm, it doesn't look so:
> % select p
2016-03-10 22:24 GMT+01:00 Robert Haas :
>
> rhaas=# select query, state, wait_event, wait_event_type from
> pg_stat_activity;
> query
> | state | wait_event | wait_event_type
>
> -+
2016-03-11 0:17 GMT+01:00 Tom Lane :
> Robert Haas writes:
> > Or ... maybe this is intentional behavior? Now that I think about it,
> > doesn't each backend cache this info the first time its transaction
> > reads the data?
>
> Your view of pg_stat_activity is supposed to hold still within a
>
>
> Yes, I think we use this rubric quite often, and I agree it's a good one.
>
> > Trying to e.g. select a different number of columns into a different
> > number of variables in a PL/pgSQL function doesn't throw an error.
> > Bad. :(
>
> Yeah, I'm sympathetic to that request. That seems like poo
2016-03-11 22:08 GMT+01:00 Robert Haas :
> On Fri, Mar 11, 2016 at 3:44 PM, Joel Jacobson wrote:
> > On Fri, Mar 11, 2016 at 11:14 AM, Robert Haas
> wrote:
> >> I'm not direly opposed to most of what's on that page,
> >> but I'm not excited about most of it, either.
> >
> > May I ask, what impro
2016-03-11 22:32 GMT+01:00 Joel Jacobson :
> On Sat, Mar 12, 2016 at 4:08 AM, Robert Haas
> wrote:
> >
> > I don't think my experience in this area is as deep as you seem to
> > think. I can tell you that most of the requests EnterpriseDB gets for
> > PL/pgsql enhancements involve wanting it to
2016-03-11 22:48 GMT+01:00 Joel Jacobson :
> On Sat, Mar 12, 2016 at 4:41 AM, Pavel Stehule
> wrote:
> > I afraid so you try to look on your use case as global/generic issue. The
> > PL/SQL, ADA. PL/pgSQL are verbose languages, and too shortcuts does the
> > languages
2016-03-11 23:22 GMT+01:00 Joel Jacobson :
> On Sat, Mar 12, 2016 at 5:09 AM, Pavel Stehule
> wrote:
> >> What we need is more input on proposed changes from other companies
> >> who are also heavy users of PL/pgSQL.
> >>
> >> Only then can we move forwa
Hi
2016-03-09 18:41 GMT+01:00 Corey Huinker :
>
>>> The regression tests seem to adequately cover all new functionality,
>>> though I wonder if we should add some cases that highlight situations where
>>> BINARY mode is insufficient.
>>>
>>>
> One thing I tried to test RAW was to load an existing
2016-03-11 14:49 GMT+01:00 Robert Haas :
> On Thu, Feb 18, 2016 at 9:23 AM, Daniel Verite
> wrote:
> > Dean Rasheed wrote:
> >
> >> If I want to sort the rows coming out of a query, my first thought
> >> is always going to be to add/adjust the query's ORDER BY clause, not
> >> use some we
2016-03-14 20:38 GMT+01:00 Tom Lane :
> Robert Haas writes:
> > On Mon, Mar 14, 2016 at 12:04 PM, Tom Lane wrote:
> >> Or in short: maybe it's time to blow up %TYPE and start fresh.
>
> > That's not a dumb idea. I think %TYPE is an Oracle-ism, and it
> > doesn't seem to have been their best-eve
2016-03-14 17:39 GMT+01:00 Teodor Sigaev :
> I afraid so I cannot to fix this inconsistency (if this is inconsistency -
>> the
>> binary values are same) - the parameter of function is raw string with
>> processed
>> escape codes, and I have not any information about original escape
>> sequences.
Hi
2016-03-16 5:01 GMT+01:00 Kyotaro HORIGUCHI :
> Hello,
>
> # It seems that I have been forgotten in the recepient list..
>
> At Tue, 15 Mar 2016 22:09:59 -0400, Peter Eisentraut
> wrote in <56e8c077.2000...@gmx.net>
> > On 2/5/16 3:09 AM, Kyotaro HORIGUCHI wrote:
> > > I considered how to mak
2016-03-16 16:50 GMT+01:00 Pavel Stehule :
>
>
> 2016-03-16 16:46 GMT+01:00 Joe Conway :
>
>> On 03/15/2016 05:17 PM, Tom Lane wrote:
>> > In short, I think we should reject this implementation and instead try
>> > to implement the type operators we
Hi
2016-03-14 17:39 GMT+01:00 Teodor Sigaev :
> I afraid so I cannot to fix this inconsistency (if this is inconsistency -
>> the
>> binary values are same) - the parameter of function is raw string with
>> processed
>> escape codes, and I have not any information about original escape
>> sequenc
Hi
2016-03-13 20:24 GMT+01:00 Jim Nasby :
> On 3/3/16 8:51 AM, Pavel Stehule wrote:
>
>> Hi
>>
>> I am testing behave, and some results looks strange
>>
>
> Thanks for the review!
>
> postgres=# \sf foo
>> CREATE OR REPLACE FUNCTION public.foo
2016-03-17 0:39 GMT+01:00 Tom Lane :
> Jim Nasby writes:
> > On 3/3/16 4:51 AM, Pavel Stehule wrote:
> >> CREATE TABLE a(a int);
> >> CREATE TABLE b(a a.a%TYPE)
> >>
> >> And the people expecting the living relation between table a and table
>
2016-03-17 1:02 GMT+01:00 David G. Johnston :
> On Wed, Mar 16, 2016 at 4:39 PM, Tom Lane wrote:
>
>> Jim Nasby writes:
>> > On 3/3/16 4:51 AM, Pavel Stehule wrote:
>> >> CREATE TABLE a(a int);
>> >> CREATE TABLE b(a a.a%TYPE)
>> >>
&
2016-03-16 16:46 GMT+01:00 Joe Conway :
> On 03/15/2016 05:17 PM, Tom Lane wrote:
> > In short, I think we should reject this implementation and instead try
> > to implement the type operators we want in the core grammar's Typename
> > production, from which plpgsql will pick it up automatically.
Hi
2016-03-17 21:02 GMT+01:00 Pavel Stehule :
> Hi
>
>
> I am looking this patch. It looks well, but this feature doesn't respect
> upper or lower chars. It enforce upper chars. This is not consistent with
> any other autocomplete.
>
I checked it against sql help an
2016-03-19 15:45 GMT+01:00 Robert Haas :
> On Mon, Mar 14, 2016 at 2:55 PM, Robert Haas
> wrote:
> > On Sat, Mar 12, 2016 at 10:34 AM, Daniel Verite
> wrote:
> >>> But worse than either of those things, there is no real
> >>> agreement on what the overall design of this feature
> >>> should be.
2016-03-16 20:53 GMT+01:00 Jim Nasby :
> On 3/3/16 4:51 AM, Pavel Stehule wrote:
>
>> CREATE TABLE a(a int);
>> CREATE TABLE b(a a.a%TYPE)
>>
>> And the people expecting the living relation between table a and table
>> b. So when I do ALTER a.a, then b.a shou
2016-03-18 16:32 GMT+01:00 David Steele :
> On 3/12/16 1:24 AM, Pavel Stehule wrote:
>
> Great, thank you very much. I hope so this feature really useful. It
>> allow to simple export/import XML doc in different encodings, JSONs and
>> can be enhanced future via options. T
2016-03-16 17:54 GMT+01:00 Vik Fearing :
> On 03/16/2016 05:32 PM, Robert Haas wrote:
>
> > Committed with slight changes to the docs, and I added a flag variable
> > instead of relying on IdleInTransactionSessionTimeout not changing at
> > an inopportune time.
>
> Thank you!
>
great, important f
2016-03-18 16:26 GMT+01:00 Teodor Sigaev :
> I hope so the messages are ok now. Few more regress tests added.
>>
>
> Thank you, committed.
Thank you very much
Pavel
>
>
> --
> Teodor Sigaev E-mail: teo...@sigaev.ru
>
Hi
2016-03-19 16:31 GMT+01:00 Alvaro Herrera :
> Pavel Stehule wrote:
>
> > Can I do review?
>
> Of course.
>
I did review of last patch. I had to do small changes to run the code due
last Tom's changes in psql. Updated patch is attached.
The last changes in this
Hi
2016-03-21 21:24 GMT+01:00 Merlin Moncure :
> Patch is trivial (see below), discussion is not :-).
>
> I see no useful reason to require INTO when returning data with
> SELECT. However, requiring queries to indicate not needing data via
> PERFORM causes some annoyances:
>
> *) converting rout
2016-03-21 23:03 GMT+01:00 Merlin Moncure :
> On Mon, Mar 21, 2016 at 4:13 PM, Pavel Stehule
> wrote:
> > Hi
> >
> > 2016-03-21 21:24 GMT+01:00 Merlin Moncure :
> >>
> >> Patch is trivial (see below), discussion is not :-).
> >>
> >>
2016-03-21 23:26 GMT+01:00 Jim Nasby :
> On 3/21/16 5:03 PM, Merlin Moncure wrote:
>
>> in Oracle, you'd simply do:
>> LogIt('I did something');
>>
>
> It would be *great* if we could support that in plpgsql.
>
> I'm not sure what Oracle does for SELECT statements without INTO/BULK
>> UPDATE. I'm
2016-03-21 23:49 GMT+01:00 Tom Lane :
> Jim Nasby writes:
> > On 3/21/16 5:03 PM, Merlin Moncure wrote:
> >> in Oracle, you'd simply do:
> >> LogIt('I did something');
>
> > It would be *great* if we could support that in plpgsql.
>
> FWIW, I'm hesitant to just start accepting that syntax as if i
Hi
is it expected in this moment?
Table "public.foo"
Column │ Type │ Modifiers
╪═╪═══
a │ integer │
postgres=# \d foo2
Table "public.foo2"
Column │ Type │ Modifiers
╪═╪═══
a │ numeric │
postgres=# explain select sum
2016-03-22 6:06 GMT+01:00 Tom Lane :
> Pavel Stehule writes:
> > I can live with SELECT fx(x). It is little bit dangerous, but this risk
> can
> > be easy detected by plpgsql_check.
>
> Dangerous how?
>
I afraid of useless and forgotten call of functions. But the ris
2016-03-22 6:28 GMT+01:00 David Rowley :
>
> On 22/03/2016 5:24 pm, "Pavel Stehule" wrote:
> >
> > Hi
> >
> > is it expected in this moment?
> >
> >
> > Table "public.foo"
> > Column │ Type │ Modifiers
> &
Hi
2016-03-28 6:14 GMT+02:00 Sridhar N Bamandlapally :
> Hi
>
> Is there any way to create nested function?
>
Some languages supports this feature, like plv8, but plpgsql doesn't
support it,
You have to use two function and some implementation of session variables.
Regards
Pavel
>
> oracle t
2016-03-29 5:12 GMT+02:00 Andrew Dunstan :
>
>
> On 03/28/2016 06:26 PM, Tom Lane wrote:
>
>> Pavel Stehule writes:
>>
>>> [ copy-raw-format-20160227-03.patch ]
>>>
>> I looked at this patch. I'm having a hard time accepting that it has
>
Hi
2016-03-29 0:26 GMT+02:00 Tom Lane :
> Pavel Stehule writes:
> > [ copy-raw-format-20160227-03.patch ]
>
> I looked at this patch. I'm having a hard time accepting that it has
> a use-case large enough to justify it, and here's the reason: it's
> a proto
Hi
>>> Anyway this is certainly not committable as-is, so I'm setting it back
>>> to Waiting on Author. But the fact that both libpq and ecpg would need
>>> updates makes me question whether we can safely pretend that this isn't
>>> a protocol break.
>>>
>>>
>>>
>>
>>
>> In that case I humbly su
masters.net>
> > Hi Kyotaro,
> >
> > On 3/18/16 3:22 AM, Pavel Stehule wrote:
> >
> > > I am looking this patch. It looks well, but this feature doesn't
> > > respect upper or lower chars. It enforce upper chars. This is not
> > > c
2016-03-29 12:08 GMT+02:00 Kyotaro HORIGUCHI <
horiguchi.kyot...@lab.ntt.co.jp>:
> Hi, Pavel.
>
> At Tue, 29 Mar 2016 09:59:01 +0200, Pavel Stehule
> wrote in <
> cafj8prdepggymz2axgtl33pud7x+xieao++wa+v9nqpqiyd...@mail.gmail.com>
> > > >
Hi
2016-03-29 0:26 GMT+02:00 Tom Lane :
> Pavel Stehule writes:
> > [ copy-raw-format-20160227-03.patch ]
>
> I looked at this patch. I'm having a hard time accepting that it has
> a use-case large enough to justify it, and here's the reason: it's
> a proto
Hi
2016-03-29 18:19 GMT+02:00 Tom Lane :
> Pavel Stehule writes:
> > I tested COPY RAW on old psql clients - and it is working without any
> > problem - so when the client uses same logic as psql, then it should to
> > work. Sure, there can be differently implemented
2016-03-29 20:59 GMT+02:00 Tom Lane :
> Pavel Stehule writes:
> > I am writing few lines as summary:
>
> > 1. invention RAW_TEXT and RAW_BINARY
> > 2. for RAW_BINARY: PQbinaryTuples() returns 1 and PQfformat() returns 1
> > 3.a for RAW_TEXT: PQbinaryTuples() retur
2016-03-30 5:43 GMT+02:00 Kyotaro HORIGUCHI :
> Hello,
>
> At Tue, 29 Mar 2016 13:12:06 +0200, Pavel Stehule
> wrote in kpzfw1+af_lutm...@mail.gmail.com>
> > 2016-03-29 12:08 GMT+02:00 Kyotaro HORIGUCHI <
> > > > > As mentioned before, upper-lower prob
Hi
...
>> =# alter table if
>> =# alter table if exists
>> ==
>> =# alter table I
>> =# alter table IF EXISTS// "information_schema" doesn't match.
>>
>> Since this is another problem from IF (NOT) EXISTS, this is
>> in separate form.
>>
>> What do you think about this?
>>
>
> +1
>
The ne
Hi
2016-03-29 20:59 GMT+02:00 Tom Lane :
> Pavel Stehule writes:
> > I am writing few lines as summary:
>
> > 1. invention RAW_TEXT and RAW_BINARY
> > 2. for RAW_BINARY: PQbinaryTuples() returns 1 and PQfformat() returns 1
> > 3.a for RAW_TEXT: PQbinaryTuples() ret
2016-01-12 16:52 GMT+01:00 Vladimir Sitnikov :
> > I don't know if there is a good solution except disabling server
> prepared statements.
>
> Why doesn't backend reuse already existing good plan?
>
probably good plan is more expensive than wrong plan :(
this logic is driven by plan cost, not by
2016-01-12 17:01 GMT+01:00 Vladimir Sitnikov :
> VS>>Why doesn't backend reuse already existing good plan?
> PS>this logic is driven by plan cost, not by plan execution time.
>
> It do understand that currently PG replans with $1, $2 and uses
> default selectivities for that.
>
> What I am asking
2016-01-11 20:11 GMT+01:00 Jim Nasby :
> On 1/11/16 12:46 PM, Pavel Stehule wrote:
>
>> 2016-01-11 19:41 GMT+01:00 Jim Nasby > <mailto:jim.na...@bluetreble.com>>:
>>
>> On 1/11/16 12:33 PM, Pavel Stehule wrote:
>>
>> 1. break compatibili
2016-01-12 17:59 GMT+01:00 Catalin Iacob :
> On Tue, Jan 12, 2016 at 5:50 PM, Pavel Stehule
> wrote:
> > Error and Fatal exception classes are introduced in my patch - it was
> Peter'
> > request (if I remember it well), and now I am thinking so it is not good
>
2016-01-13 11:44 GMT+01:00 Vladimir Sitnikov :
> >the implementation is simply - but it hard to design some really general
> - it is task for UI
>
> Can you please rephrase?
>
Sorry - It is task for artifical inteligency
>
> Current design is "if the cost of a generic plan is less than the one
>
2016-01-13 16:18 GMT+01:00 Albe Laurenz :
> Pavel Stehule wrote:
> > I like a strategy based on risks. Probably there are situation, when the
> generic plan is great every
> > time - INSERTs, UPDATEs via PK, simple SELECTs via PK. generic plan can
> be well if almost all
2016-01-13 16:22 GMT+01:00 Vladimir Sitnikov :
> >A value of -1 could disable generic plans
>
> I do not like the idea.
>
> I've seen dramatic performance improvements from using cached plans.
> The numbers are like "20ms to plan vs 1ms to execute" for an often
> used OLTP query. Query text is inv
2016-01-13 17:12 GMT+01:00 Vladimir Sitnikov :
> >If plan is ok for one value parameters, then can be pretty bad for
> following parameters.
>
> Happy statements are all alike; every unhappy statement is unhappy in
> its own way (see [1]).
> If user is sending different kinds of parameters, he is
2016-01-14 19:51 GMT+01:00 Robert Haas :
> On Thu, Jan 14, 2016 at 12:13 PM, Marko Tiikkaja wrote:
> > SET syntax for INSERT was brought up a few years ago here:
> >
> http://www.postgresql.org/message-id/2c5ef4e30908251010s46d9d566m1da21357891ba...@mail.gmail.com
> >
> > From the discussion it s
2016-01-14 20:09 GMT+01:00 Marko Tiikkaja :
> On 2016-01-14 8:06 PM, Pavel Stehule wrote:
>
>> Probably there is less risk than 7 years ago, but still creating own
>> syntax
>> isn't the best idea. This is syntactic sugar only and different from ANSi
>> S
2016-01-12 17:27 GMT+01:00 Marko Tiikkaja :
> On 03/01/16 22:49, Jim Nasby wrote:
>
>> In the unit test, I'd personally prefer just building a table with the
>> test cases and the expected NULL/NOT NULL results, at least for all the
>> calls that would fit that paradigm. That should significantly
>
> > # explain analyze select a%100,length(string_agg(b,',')) from ab
> group
> > by 1;
> > QUERY PLAN
> >
> ---
> >
2016-01-18 22:21 GMT+01:00 Robert Haas :
> On Mon, Jan 18, 2016 at 3:51 PM, Alvaro Herrera
> wrote:
> > BTW are we all agreed that enabling
> > foo%ARRAYTYPE
> > and
> > foo%ELEMENTYPE
> > in plpgsql's DECLARE section is what we want for this?
>
> I know that Oracle uses syntax of this genera
2016-01-18 23:50 GMT+01:00 Thomas Kellerer :
> Robert Haas wrote:
> > This isn't the first complaint about this mechanism that we've gotten,
> > and it won't be the last. Way too many of our users are way more
> > aware than they should be that the threshold here is five rather than
> > any other
2016-01-18 22:48 GMT+01:00 Robert Haas :
> On Mon, Jan 18, 2016 at 4:35 PM, Pavel Stehule
> wrote:
> >> I know that Oracle uses syntax of this general type, but I've always
> >> found it ugly. It's also pretty non-extensible. You could want
> >> s
2016-01-19 13:42 GMT+01:00 Robert Haas :
> On Mon, Jan 18, 2016 at 6:56 PM, Vitaly Burovoy
> wrote:
> > On 1/4/16, Robert Haas wrote:
> >> On Mon, Jan 4, 2016 at 10:17 AM, Pavel Stehule >
> >> wrote:
> >>> [ new patch ]
> >>
>
2016-01-20 0:34 GMT+01:00 Robert Haas :
> On Tue, Jan 19, 2016 at 4:53 AM, Pavel Stehule
> wrote:
> > It is, but sometime the polymorphic types can help.
> >
> > The proposed feature/syntax has sense primary for polymorphic types. It
> > should to follow our polym
2016-01-20 3:47 GMT+01:00 Tatsuo Ishii :
> test=# select format('%I', t) from t1;
> format
> --
> aaa
> "AAA"
> "あいう"
> (3 rows)
>
> Why is the text value of the third line needed to be double quoted?
> (note that it is a multi byte character). Same thing can be said to
> quote_ident(
Hi
2016-01-19 22:34 GMT+01:00 Jim Nasby :
> I'm using the TRANSFORM feature to implement a new data type for python
> (ndarrays from numpy). I'm constantly getting tripped up by forgetting to
> add TRANSFORM FOR TYPE. Worse, the requirement for explicitly stating
> transform means I can't use a p
Hi
2016-01-20 7:20 GMT+01:00 Tatsuo Ishii :
> > 2016-01-20 3:47 GMT+01:00 Tatsuo Ishii :
> >
> >> test=# select format('%I', t) from t1;
> >> format
> >> --
> >> aaa
> >> "AAA"
> >> "あいう"
> >> (3 rows)
> >>
> >> Why is the text value of the third line needed to be double quoted?
> >>
2016-01-20 10:17 GMT+01:00 Tatsuo Ishii :
> > Hi
> >
> > 2016-01-20 7:20 GMT+01:00 Tatsuo Ishii :
> >
> >> > 2016-01-20 3:47 GMT+01:00 Tatsuo Ishii :
> >> >
> >> >> test=# select format('%I', t) from t1;
> >> >> format
> >> >> --
> >> >> aaa
> >> >> "AAA"
> >> >> "あいう"
> >> >> (3 rows
Hi
2016-01-19 0:56 GMT+01:00 Vitaly Burovoy :
> On 1/4/16, Robert Haas wrote:
> > On Mon, Jan 4, 2016 at 10:17 AM, Pavel Stehule
> > wrote:
> >> [ new patch ]
> >
> > + case '-':
> > + ereport(ERROR,
> > +
2016-01-19 4:45 GMT+01:00 Vitaly Burovoy :
> On 1/4/16, Pavel Stehule wrote:
> > 2016-01-04 18:13 GMT+01:00 Shulgin, Oleksandr <
> oleksandr.shul...@zalando.de> :
> >> On Mon, Jan 4, 2016 at 6:03 PM, Pavel Stehule
> wrote:
> >> > 2016-01-04 17:48 GMT+0
2016-01-21 3:33 GMT+01:00 Peter Eisentraut :
> On 1/18/16 10:58 AM, Alvaro Herrera wrote:
> > Peter Eisentraut wrote:
> >> I have written a couple of patches to improve the integration of the
> >> postgres daemon with systemd.
> >
> > Great. Is anything happening with these patches, or? They've
2016-01-21 11:51 GMT+01:00 Vitaly Burovoy :
> On 1/20/16, Pavel Stehule wrote:
> > ...
> > New version is attached
> >
> > Regards
> > Pavel
>
> I'm sorry I'll do a review only tonight.
>
ook :)
Thank you
Pavel
> --
> Best regards,
> Vitaly Burovoy
>
Hi
2016-01-17 8:43 GMT+01:00 Pavel Stehule :
>
>
> 2016-01-12 17:27 GMT+01:00 Marko Tiikkaja :
>
>> On 03/01/16 22:49, Jim Nasby wrote:
>>
>>> In the unit test, I'd personally prefer just building a table with the
>>> test cases and the expec
2016-01-14 17:16 GMT+01:00 Catalin Iacob :
> On Wed, Jan 13, 2016 at 7:40 PM, Jim Nasby
> wrote:
> > On 1/12/16 11:25 AM, Catalin Iacob wrote:
> >> They're similar but not really the same thing. raise Error and
> >> plpy.error are both ways to call ereport(ERROR, ...) while SPIError is
> >> raise
2016-01-22 7:03 GMT+01:00 Vitaly Burovoy :
> On 1/20/16, Pavel Stehule wrote:
> > ...
> > New version is attached
> >
> > Regards
> > Pavel
>
> Hello!
>
> 1. Why the function is marked as VOLATILE? It depends only on input
> value, it does
Hi
2016-01-23 16:36 GMT+01:00 Tom Lane :
> Michael Paquier writes:
> > On Sat, Jan 23, 2016 at 1:25 AM, Marko Tiikkaja wrote:
> > + errmsg("identifier contains disallowed chars"),
> > + errdetail("string \"%s\" is not valid identifier",
> > +
Hi
2016-01-22 19:53 GMT+01:00 Daniel Verite :
> Hi,
>
> Here's an updated patch improving on how the horizontal and vertical
> headers can be sorted.
>
> The discussion upthread went into how it was desirable
> to have independant sorts for these headers, possibly driven
> by another column, in
2016-01-22 13:34 GMT+01:00 Jim Nasby :
> On 1/21/16 1:48 PM, Pavel Stehule wrote:
>
>> the form of regress tests is not pretty significant issue. Jim's
>> design is little bit transparent, Marko's is maybe little bit
>> practical. Both has sen
Hi
Vitaly Burovoy pointed on bug in my patch - a pg_size_bytes was VOLATILE
function. It is copy/paste bug - I used pg_size_pretty definition, so the
question is: why pg_size_pretty is volatile? It should be immutable too.
Regards
Pavel
Hi
2016-01-22 7:03 GMT+01:00 Vitaly Burovoy :
> On 1/20/16, Pavel Stehule wrote:
> > ...
> > New version is attached
> >
> > Regards
> > Pavel
>
> Hello!
>
> 1. Why the function is marked as VOLATILE? It depends only on input
> value, it does
1 - 100 of 5142 matches
Mail list logo
