2016-01-26 2:00 GMT+01:00 Michael Paquier :
> On Tue, Jan 26, 2016 at 5:35 AM, Pavel Stehule
> wrote:
> > 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 i
Hi
2016-01-26 6:25 GMT+01:00 Vitaly Burovoy :
> Hello!
>
>
> Regression tests are present (see p.II).
>
> pg_proc.h has changed, so the CATALOG_VERSION_NO must be also changed.
>
this is not a part of patch - only a commiter knows CATALOG_VERSION_NO
>
> Code comments, error message string, DES
2016-01-26 7:31 GMT+01:00 Catalin Iacob :
> On 1/21/16, Pavel Stehule wrote:
> > 2016-01-14 17:16 GMT+01:00 Catalin Iacob :
> >> Consider this call chain: SQL code 1 -> PL/Python code 1 -> SPI (via
> >> plpy.execute) -> SQL code 2 -> PL/Python code 2
> &
2016-01-26 8:22 GMT+01:00 Pavel Stehule :
>
>
> 2016-01-26 7:31 GMT+01:00 Catalin Iacob :
>
>> On 1/21/16, Pavel Stehule wrote:
>> > 2016-01-14 17:16 GMT+01:00 Catalin Iacob :
>> >> Consider this call chain: SQL code 1 -> PL/Python code 1 -> SPI
2016-01-26 11:42 GMT+01:00 Marko Tiikkaja :
> On 25/01/16 19:57, Pavel Stehule wrote:
>
>> Marco is a author of this patch, so - Marco, please, send final version of
>> this patch
>>
>
> I don't really care about the tests. Can we not use the v5 patch already
tly about a code design.
>
> 26.01.2016 07:05, Pavel Stehule пишет:
> >> pg_proc.h has changed, so the CATALOG_VERSION_NO must be also changed.
> > this is not a part of patch - only a commiter knows CATALOG_VERSION_NO
> >
> CATALOG_VERSION_NO is mentioned for a committer, it
Hi
>>> But in my opinion this discussion shouldn't really even be about
>>> catching these things, most of the times you won't catch them and
>>> instead you'll let them go to Postgres. The discussion should be
>>> whether raise plpy.Error(...), plpy.raise_error, plpy.raise_info(,,,)
>>> etc. all
2016-01-26 21:00 GMT+01:00 Daniel Verite :
> Tatsuo Ishii wrote:
>
> > IMO, it's a bug or at least an inconsistency
>
> Personally I don't see this change being good for everything.
>
> Let's play devil's advocate:
>
> create table abc(U&"foo\2003" int);
>
> U+2003 is 'EM SPACE', in Unicod
2016-01-27 6:13 GMT+01:00 Tatsuo Ishii :
> > 2016-01-26 21:00 GMT+01:00 Daniel Verite :
> >
> >> Tatsuo Ishii wrote:
> >>
> >> > IMO, it's a bug or at least an inconsistency
> >>
> >> Personally I don't see this change being good for everything.
> >>
> >> Let's play devil's advocate:
> >>
2016-01-27 6:24 GMT+01:00 Tatsuo Ishii :
> >> > I can agree, so current behave can be useful in some cases, but still
> it
> >> is
> >> > bug (inconsistency) between PostgreSQL parser and PostgreSQL escaping
> >> > functions.
> >> >
> >> > Currently, any multibyte char can be unescaped identifier
2016-01-27 8:25 GMT+01:00 Tatsuo Ishii :
> >> What do you exactly propose regarding white chars and multibyte chars
> >> here? Maybe you propose to consider non ASCII white spaces (treate
> >> them as ASCII white spaces)?
> >>
> >
> > I propose the work with UTF white chars should be same like ASC
Hi
2015-11-17 15:08 GMT+01:00 Peter Eisentraut :
> I have written a couple of patches to improve the integration of the
> postgres daemon with systemd.
>
> The setup that is shipped with Red Hat- and Debian-family packages at
> the moment is just an imitation of the old shell scripts, relying on
Hi
>
> > I though about it lot of, and I see a the core of problems in orthogonal
> > constructed exceptions in Python and Postgres. We working with statements
> > elog, ereport, RAISE EXCEPTION - and these statements are much more like
> > templates - can generate any possible exception. Python
Hi
2016-01-18 21:37 GMT+01:00 Alvaro Herrera :
> > diff --git a/src/pl/plpgsql/src/pl_comp.c b/src/pl/plpgsql/src/pl_comp.c
> > new file mode 100644
> > index 1ae4bb7..c819517
> > *** a/src/pl/plpgsql/src/pl_comp.c
> > --- b/src/pl/plpgsql/src/pl_comp.c
> > *** plpgsql_parse_tripword(
2016-01-27 19:21 GMT+01:00 Igal @ Lucee.org :
> On 1/27/2016 9:57 AM, Vladimir Sitnikov wrote:
>
>> That is a good question. ChakraCore has been open sourced recently. It
>> might be easier to build under Windows.
>>
> interesting. but now we will need to write an extension for that, e.g.
> PL/Ch
2016-01-27 19:37 GMT+01:00 Pavel Stehule :
>
>
> 2016-01-27 19:21 GMT+01:00 Igal @ Lucee.org :
>
>> On 1/27/2016 9:57 AM, Vladimir Sitnikov wrote:
>>
>>> That is a good question. ChakraCore has been open sourced recently. It
>>> might be easier to build u
Hi
2016-01-28 3:50 GMT+01:00 Peter Eisentraut :
> On 1/27/16 7:02 AM, Pavel Stehule wrote:
> > The issues:
> >
> > 1. configure missing systemd integration test, compilation fails:
> >
> > postmaster.o postmaster.c
> > postmaster.c:91:31: fatal erro
>
> > Second issue:
> >
> > Mapping of levels between pg and journal levels is moved by1
>
> This is the same as how the "syslog" destination works.
>
>
I understand to this logic, but I miss any documentation.
Regards
Pavel
Hi
>
> >
> > You sent only rebased code of previous version. I didn't find additional
> > checks.
>
> Oops. Here is the actual new code.
>
>
New test is working as expected
I did lot of tests - and this code works perfect in single server mode, and
with slave hot-standby mode.
It doesn't work w
2016-01-30 22:38 GMT+01:00 Peter Eisentraut :
> On 1/29/16 4:15 PM, Pavel Stehule wrote:
> > Hi
> >
> > >
> > >
> > > You sent only rebased code of previous version. I didn't find
> additional
> > > checks.
> >
&g
Hi
> P.S.: Have you thought to wrap the call "numeric_in" by a
> PG_TRY/PG_CATCH instead of checking for correctness by yourself?
>
I though about it, but it is not possible. Every PG_TRY/CATCH must be
finished by RETHROW. Only when you will open subtransaction and you are
playing with resource
Hi
> index 2e7f1d7..d983a50 100644
> --- a/src/backend/postmaster/postmaster.c
> +++ b/src/backend/postmaster/postmaster.c
> @@ -4933,6 +4933,11 @@ sigusr1_handler(SIGNAL_ARGS)
> if (XLogArchivingAlways())
> PgArchPID = pgarch_start();
>
> +#ifdef USE_SYSTEMD
> + if (!Ena
hi
I am sorry, I am writing from mobile phone and I cannot to cutting text
well.
Dne 29. 1. 2016 18:09 napsal uživatel "Catalin Iacob" <
iacobcata...@gmail.com>:
This interface is new generation of previous
> > functions: info, notice, warning, error with keyword parameters
interface. I
> > didn'
Dne 2. 2. 2016 7:30 napsal uživatel "Catalin Iacob" :
>
> On Mon, Feb 1, 2016 at 5:37 PM, Pavel Stehule
wrote:
> > Dne 29. 1. 2016 18:09 napsal uživatel "Catalin Iacob"
> > :
> >> Looking at the output above, I don't see who would rely on
Dne 3. 2. 2016 20:51 napsal uživatel "Daniel Verite" <
dan...@manitou-mail.org>:
>
> Alvaro Herrera wrote:
>
> > https://commitfest.postgresql.org/8/372/
> > \crosstabview (previously: \rotate) in psql for crosstab-style
display
>
> About this one, the code is no longer moving, the lat
Hi
I tested last version, v11 and I have not any objection
It is working as expected
all regress tests passed, there is related documentation and new test is
attached.
This patch is ready form commiter.
Daniel, thank you very much, it is interesting feature.
Regards
Pavel
Dne 5. 2. 2016 1:33 napsal uživatel "Tom Lane" :
>
> Pavel Stehule writes:
> > [ num_nulls_v6.patch ]
>
> I started looking through this. It seems generally okay, but I'm not
> very pleased with the function name "num_notnulls". I think it would
>
2016-02-05 2:35 GMT+01:00 Peter Eisentraut :
> On 12/29/15 10:38 AM, Bruce Momjian wrote:
> > On Thu, Dec 10, 2015 at 11:10:55AM -0500, Robert Haas wrote:
> >> On Wed, Dec 9, 2015 at 12:15 AM, Pavel Stehule
> wrote:
> >>>> On Wed, Dec 9, 2015 at 2:07 PM, Pavel
Hi
On Russian PgConf I had a talk with Oleg about missing features in PLpgSQL,
that can complicates a migrations from Oracle to PostgreSQL. Currently I
see only one blocker - missing protected session variables. PL/SQL has
package variables with possible only package scope and session life cycle.
2016-02-08 13:03 GMT+01:00 Marko Tiikkaja :
> On 08/02/16 09:16, Pavel Stehule wrote:
>
>> Usage
>> =
>>
>> DROP SCHEMA IF EXISTS test_schema CASCADE;
>> SET SCHEMA test_schema;
>>
>> CREATE SCHEMA VARIABLE local_counter AS int DEFAULT 0;
&g
2016-02-08 13:22 GMT+01:00 Marko Tiikkaja :
> On 08/02/16 13:17, Pavel Stehule wrote:
>
>> 2016-02-08 13:03 GMT+01:00 Marko Tiikkaja :
>>
>>> How does this function know which schema variables are visible?
>>>
>>
>> function see all schema
2016-02-08 13:53 GMT+01:00 Marko Tiikkaja :
> On 08/02/16 13:41, Pavel Stehule wrote:
>
>> 2016-02-08 13:22 GMT+01:00 Marko Tiikkaja :
>>
>>> Personally I find that undesirable. I don't know what oracle does, but
>>> variables being visible wit
2016-02-08 16:45 GMT+01:00 jflack :
> On 02/08/2016 03:16 AM, Pavel Stehule wrote:
>
> > Only a owner of schema can edit functions inside schema
>
> Can't anyone granted CREATE on the schema do that? Would
> that be changed by this proposal?
>
yes, anybody wi
2016-02-08 16:55 GMT+01:00 Teodor Sigaev :
> rebased, messages changes per Tom's proposal
>>
> Cool feature and sometimes I needed it a lot.
>
> But, seems, there are some bugs in error processing.
>
I am looking on it
Regards
Pavel
Hi
>> I propose really basic functionality, that can be enhanced in future -
>> step by step. This proposal doesn't contain any controversial feature or
>> syntax, I hope. It is related to PLpgSQL only, but described feature can be
>> used from any PL languages with implemented interface.
>>
>
>
Hi
> FWIW I think the general idea of this feature (client-side resultset
> "pivoting") is a good one, but I don't really have an opinion regarding
> your specific proposal. I think you should first seek some more
> consensus about the proposed design; in your original thread [1] several
> guys
Hi
> I just rechecked the thread. In my reading, lots of people argued
> whether it should be called \rotate or \pivot or \crosstab; it seems the
> \crosstabview proposal was determined to be best. I can support that
> decision. But once the details were discussed, it was only you and
> Daniel
Hi
Looking at this patch, I have mixed feelings about it. On the one hand
> I really like the look of the output, and I can see that the non-fixed
> nature of the output columns makes this hard to achieve server-side.
>
> But on the other hand, this seems to be going way beyond the normal
> level
> >
> > SELECT name, to_char(date, 'mon') AS month, extract(month from date) AS
> > month_order, sum(amount) AS amount FROM invoices GROUP BY 1,2,3;
> >
> > and crosstabview command (per Daniel proposal)
> >
> > \crosstabview +name +month:month_order amount
> >
> > But if I don't need column heade
2016-02-09 15:32 GMT+01:00 Marko Tiikkaja :
> On 08/02/16 14:16, Pavel Stehule wrote:
>
>> 2016-02-08 13:53 GMT+01:00 Marko Tiikkaja :
>>
>>>
>>> Yeah, and that's exactly what I don't want, because that means that
>>> C
Hi
2016-02-08 16:55 GMT+01:00 Teodor Sigaev :
> rebased, messages changes per Tom's proposal
>>
> Cool feature and sometimes I needed it a lot.
>
> But, seems, there are some bugs in error processing.
>
> 1
> Following query is okay:
> # select * from parse_ident(E'"Some \r Schema".someTable');
>
I haven't been paying attention to this thread ... but it is sure
> sounding like this feature has gotten totally out of hand. Suggest
> reconsidering your design goals.
>
> > Or said otherwise, having the [+/-] colV sorting is a way to
> > avoid the question:
> > "we can sort the horizontal heade
Hi
sorry, I am sending missing attachment
Regards
Pavel
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
new file mode 100644
index f9eea76..bfba459
*** a/doc/src/sgml/func.sgml
--- b/doc/src/sgml/func.sgml
***
*** 1821,1826
--- 1821,1843
Hi
Would it make sense to explicitly import variables in function definitions?
>
> CREATE SESSION VARIABLE foo integer;
> CREATE SESSION VARIABLE my_schema.bar text;
> SET SESSION VARIABLE foo to 4;
> SET SESSION VARIABLE my_schema.bar to 'hi mom';
>
> CREATE FUNCTION my_func (p_param text) return
2016-02-09 20:55 GMT+01:00 David G. Johnston :
> On Tue, Feb 9, 2016 at 11:32 AM, Corey Huinker
> wrote:
>
>>
>> Oh, and I suggest we call them SESSION variables rather than SCHEMA
>> variables, to reinforce the idea of how long the values in the variables
>> live. A session variable is in a sens
2016-02-09 23:31 GMT+01:00 Jim Nasby :
> On 2/8/16 10:02 AM, Pavel Stehule wrote:
>
>>
>> I think it would make sense to implement the interface in at least
>> one of our other supported PLs. I'm not entirely clear how well this
>> will mat
Hi
2016-02-09 23:41 GMT+01:00 Jim Nasby :
> On 2/9/16 4:13 PM, Corey Huinker wrote:
>
>>
>> We're not going to get source compatibility without implementing
>> packages, and there's no enthusiasm for that. It's been stated a few
>> times before by some that the only value they see in packages is
Hi Vitaly,
please, can you send your version of this patch, how we talked about it in
Moscow?
Thank you
Pavel
Hi
>
>> Actually I imagine that if there's no agreement between author and first
>> reviewer, there might not *be* a committer in the first place. Perhaps
>> try to get someone else to think about it and make a decision. It is
>> possible that some other committer is able to decide by themselv
>> I didn't propose SESSION variables - now there are some workarounds how
>> to anybody can emulate it, so this feature can wait. What we need is
>> safe session variables with limited access. And the border can be
>> defined by schema scope. So the keyword SCHEMA has sense, and it is
>> necessary
2016-02-10 20:10 GMT+01:00 Jim Nasby :
> On 2/10/16 1:04 PM, Pavel Stehule wrote:
>
>>
>> BTW, if all that's desired here are session variables for plpgsql, I
>> think it makes a lot more sense to start with implementing
>> per-function session var
>>
>> The schema variables are private by design. It can be enhanced in
>> future, but now it is out my scope. If you need public access to these
>> variables, you can use a functions. The access to functions can be
>> controlled by a rights. We can introduce a private (schema limited)
>> function
2016-02-10 20:25 GMT+01:00 Jim Nasby :
> On 2/10/16 1:17 PM, Pavel Stehule wrote:It is too simple and too like
> workaround :) I can do it this in plpgsql
>
>> extension probably.
>>
>
> I think it's something people will definitely want. If we don't have
2016-02-10 19:26 GMT+01:00 Jim Nasby :
> The following review has been posted through the commitfest application:
> make installcheck-world: tested, passed
> Implements feature: tested, passed
> Spec compliant: not tested
> Documentation:not tested
>
> NEEDS CATVERSION
2016-02-11 7:44 GMT+01:00 Vitaly Burovoy :
> On 2/10/16, Pavel Stehule wrote:
> > Hi Vitaly,
> >
> > please, can you send your version of this patch, how we talked about it
> in
> > Moscow?
> >
> > Thank you
> >
> > Pavel
>
> Hello,
This is last incarnation of my patch (cleaned and refactored by Vitaly Burovoy)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hi
assigned https://commitfest.postgresql.org/9/514/
Regards
Pavel
Hi
2016-02-11 7:44 GMT+01:00 Vitaly Burovoy :
> On 2/10/16, Pavel Stehule wrote:
> > Hi Vitaly,
> >
> > please, can you send your version of this patch, how we talked about it
> in
> > Moscow?
> >
> > Thank you
> >
> > Pavel
>
> Hello,
Thinking about this some more though, perhaps *sorting* the columns is
> the wrong way to be thinking about it. Perhaps a better approach would
> be to allow the columns to be *listed* (optionally, using a separate
> query). Something like the following (don't get too hung up on the
> syntax):
>
>
2016-02-11 18:29 GMT+01:00 Magnus Hagander :
> Most of the pl/pgsql functions and variables are prefixed plpgsql_, so
> they don't risk conflicting with other shared libraries loaded.
>
> There are a couple that are not prefixed. Attached patch fixes that. It's
> mostly a cleanup, but I think it's
> most recent error in verbose mode, without making a permanent session
> > state change. Something like
> >
> > regression=# insert into bar values(1);
> > ERROR: insert or update on table "bar" violates foreign key constraint
> "bar_f1_fkey"
> > DETAIL: Key (f1)=(1) is not present in table "f
Hi
2016-02-12 2:28 GMT+01:00 Vitaly Burovoy :
> Hello!
>
> On 2/11/16, Pavel Stehule wrote:
> > Hi
> >
> > assigned https://commitfest.postgresql.org/9/514/
> >
> > Regards
> > Pavel
>
>
> This patch was almost done by the end of the previo
2016-02-10 17:21 GMT+01:00 Robert Haas :
> On Wed, Feb 10, 2016 at 11:08 AM, Heikki Linnakangas
> wrote:
> > On 10/02/16 17:12, Robert Haas wrote:
> >> Code cleanup in the wake of recent LWLock refactoring.
> >>
> >> As of commit c1772ad9225641c921545b35c84ee478c326b95e, there's no
> >> longer an
There will be necessary more changes than this. Orafce has some parts based
> on lw locks. I am able to compile it without any issue. But the lock
> mechanism is broken now - so impact on extensions will be higher. Have to
> do some research.
>
if somebody would to use it for testing
https://gith
2016-02-12 10:37 GMT+01:00 Amit Kapila :
> On Fri, Feb 12, 2016 at 2:03 PM, Pavel Stehule
> wrote:
>
>>
>>
>> There will be necessary more changes than this. Orafce has some parts
>>> based on lw locks. I am able to compile it without any issue. But the l
2016-02-12 14:10 GMT+01:00 Robert Haas :
> On Fri, Feb 12, 2016 at 3:33 AM, Pavel Stehule
> wrote:
> >> There will be necessary more changes than this. Orafce has some parts
> >> based on lw locks. I am able to compile it without any issue. But the
> lock
> >>
2016-02-12 15:43 GMT+01:00 Robert Haas :
> On Fri, Feb 12, 2016 at 8:16 AM, Pavel Stehule
> wrote:
> >> That's very strange. It looks to me like you did exactly the right
> >> thing. Can you provide any details on how it fails?
> >
> > Looks like som
2016-02-12 15:46 GMT+01:00 Pavel Stehule :
>
>
> 2016-02-12 15:43 GMT+01:00 Robert Haas :
>
>> On Fri, Feb 12, 2016 at 8:16 AM, Pavel Stehule
>> wrote:
>> >> That's very strange. It looks to me like you did exactly the right
>> >>
2016-02-12 17:35 GMT+01:00 Pavel Stehule :
>
>
> 2016-02-12 15:46 GMT+01:00 Pavel Stehule :
>
>>
>>
>> 2016-02-12 15:43 GMT+01:00 Robert Haas :
>>
>>> On Fri, Feb 12, 2016 at 8:16 AM, Pavel Stehule
>>> wrote:
>>> >> That's
Hi
>> SQL access to variables needs a) change in SQL parser (with difficult
>> discussion about syntax) or b) generic get/set functions. @b can be used
>> in other PL in first iteration.
>>
>> I afraid to open pandora box and I would to hold the scope of this patch
>> too small what is possible
2016-02-13 4:52 GMT+01:00 Robert Haas :
> On Fri, Feb 12, 2016 at 1:08 PM, Pavel Stehule
> wrote:
> >> I got a error
> >>
> >> ERROR: XX000: requested tranche is not registered
> >> LOCATION: GetNamedLWLockTranche, lwlock.c:602
> >>
> >
2016-02-12 22:41 GMT+01:00 Jim Nasby :
> On 2/12/16 2:58 PM, Pavel Stehule wrote:
>
>> I think that's probably true, but this also shows why we need to consider
>> different PLs too. As it stands right now, the only way to access a
>> variable outside of plpgs
2016-02-13 6:32 GMT+01:00 Robert Haas :
> On Sat, Feb 13, 2016 at 12:20 AM, Pavel Stehule
> wrote:
> >> Hmm. So orafce is actually benefiting from the 3-lwlock slop that was
> >> built into the old system: if one of those original 3 locks was
> >> as-yet-u
Hi
I am sending new version. Current version does:
1. the plpy utility functions can use all ErrorData fields,
2. there are no new functions,
3. via GUC plpythonu.legacy_custom_exception we can return previous behave,
4. only exception Error is raised with natural structure - no composite
value s
Hi Jim
2016-02-11 8:27 GMT+01:00 Pavel Stehule
>
>
> ok
>
>>
>> Also added test for invalid characters.
>>
>> I think "strict" would be more in line with other uses in code. There are
>> currently no other occurrences of 'strictmode'
Hi,
the interpretation of slow queries or entries from auto-explain log can be
difficult some times, because the the main time of query evaluation is
waiting on lock, and this number isn't in related entry. Our situation is
little bit difficult, because we have not direct access to PostgreSQL logs
2016-02-14 17:46 GMT+01:00 Tom Lane :
> Pavel Stehule writes:
> > We have a patch, that inject logs about the time waiting on locks before
> > query execution. This feature helps us lot of, and I hope, it can be
> > generally useful.
>
> Doesn't log_lock_waits cov
Hi
2016-02-15 10:16 GMT+01:00 Dean Rasheed :
> > On 12/02/16 10:19, Dean Rasheed wrote:
> >> This seems like a reasonable first patch for me as a committer, so
> >> I'll take it unless anyone else was planning to do so.
> >
>
> So looking at this, it seems that for the most part pg_size_bytes()
>
Hi
2016-02-16 10:47 GMT+01:00 Kyotaro HORIGUCHI <
horiguchi.kyot...@lab.ntt.co.jp>:
> Hello.
>
> I'm planning to change the error level of a specific error
> message. We can use emit_log_hook for this purpose but we have
> no reliable means to identify what a message is.
>
> For messages without
2016-02-16 11:25 GMT+01:00 Dean Rasheed :
> On 16 February 2016 at 05:01, Pavel Stehule
> wrote:
> > 2016-02-15 10:16 GMT+01:00 Dean Rasheed :
> >> Is there any reason not to make
> >> pg_size_bytes() return numeric?
> >>
> > This is a question. I hav
2016-02-16 21:06 GMT+01:00 Catalin Iacob :
> On Tue, Feb 16, 2016 at 5:18 PM, Catalin Iacob
> wrote:
> > We have
> > elog_test_legacy to test elog_test_legacy=true, the rest of the tests
> > should use legacy_custom_exception=false.
>
> This should have been:
> We have elog_test_legacy to test le
Hi
2016-02-16 17:18 GMT+01:00 Catalin Iacob :
> On Sat, Feb 13, 2016 at 4:26 PM, Pavel Stehule
> wrote:
> > I am sending new version. Current version does:
>
> Hello,
>
> I had a look and I like the big picture.
>
> Tests fail when built against Pyth
2016-02-17 3:43 GMT+01:00 Jim Nasby :
> On 2/14/16 11:24 AM, Pavel Stehule wrote:
>
>> > We have a patch, that inject logs about the time waiting on locks
>> before
>> > query execution. This feature helps us lot of, and I hope, it can be
>> &
2016-02-17 3:19 GMT+01:00 Jim Nasby :
> On 2/16/16 12:38 AM, Michael Paquier wrote:
>
>> When a patch with status "Ready for committer" on CF N is moved to CF
>> (N+1), its status is automatically changed to "Needs Review". That's
>> something to be aware of when cleaning up the CF app entries.
>>
2016-02-17 1:38 GMT+01:00 Jim Nasby :
> On 2/11/16 1:27 AM, Pavel Stehule wrote:
>
>> I editorialized the docs and some of the comments. In particular, I
>> documented behavior of not truncating, and recommended casting to
>> name[] if user cares about th
Hi
In a entry https://commitfest.postgresql.org/9/525/ the commitfest
application show last patch
Latest attachment (incompat.py) at 2016-02-04 09:13:55 from Catalin Iacob
although last patch is from yesterday
Attachment: plpython-enhanced-error-02.patch.gz
Regards
Pavel
I noticed the patch isn't registered in the March CF, please do that.
> It would be a pity to miss 9.6 because of not registering it in time.
>
https://commitfest.postgresql.org/9/525/
Regards
Pavel
2016-02-17 9:24 GMT+01:00 Magnus Hagander :
> On Wed, Feb 17, 2016 at 6:08 AM, Pavel Stehule
> wrote:
>
>> Hi
>>
>> In a entry https://commitfest.postgresql.org/9/525/ the commitfest
>> application show last patch
>>
>> Latest attachment (incompat.
Hi
2016-02-17 7:34 GMT+01:00 Catalin Iacob :
> After I unzip the patch it doesn't apply.
> patch says:
> patch: Only garbage was found in the patch input.
>
> It's a combined diff, the git-diff manual says this about it:
> Chunk header format is modified to prevent people from accidentally
>
2016-02-17 16:54 GMT+01:00 Catalin Iacob :
> On Wed, Feb 17, 2016 at 3:32 PM, Pavel Stehule
> wrote:
> >> Python 3 has keyword only arguments. It occurs to me they're exactly
> >> for "optional extra stuff" like detail, hint etc.
> >> Python 2 does
Hi
2016-02-17 14:02 GMT+01:00 Teodor Sigaev :
> I missed some of my edits. Updated patch with those in place attached.
>>
>
> I'm sorry, but special chararacter still isn't escaped correctly in error
> messages:
>
> % select
> parse_ident(E'X\rX
Hi
2016-02-18 4:59 GMT+01:00 Pavel Stehule :
> select
>> parse_ident(E'X\rXX');
>
>
I am sending updated patch - I used json function for correct escaping -
the escaping behave is same.
Regards
Pavel
diff --git a/doc/src
2016-02-18 17:59 GMT+01:00 Catalin Iacob :
> On 2/18/16, Pavel Stehule wrote:
> > it doesn't look badly. Is there any possibility how to emulate it with
> > Python2 ? What do you think about some similar implementation on Python2?
>
> The example code I gave works
Hi
I am sending updated version - the changes are related to fix comments.
2016-02-19 10:41 GMT+01:00 Artur Zakirov :
> It seems all fixes are done. I tested the patch and regression tests
> passed.
>
> I think here Alvaro means that you should keep original comment without
> the ROW. Like this:
Hi
>> What would be useful logging-wise is if the log line for the query itself
>> could contain lock wait time, but that doesn't sound like what you're
>> proposing?
>>
>
> I hope, so I propose this idea. First time I wanted talk about the idea.
> Next step is the talk about format.
>
Some enh
> > 3) Add the concept of PL API versions. This would allow users to specify
>
> So that leaves #3, which doesn't seem all that unreasonable from here.
> We don't have a problem with bundling a bunch of unrelated changes
> into any one major PG revision. The scripting languages we're talking
> abo
> 4) Create a mechanism for specifying default TRANSFORMs for a PL, and
> essentially "solve" these issues by supplying a built-in transform.
>
> I think default transforms (4) are worth doing no matter what. Having to
> manually remember to add potentially multiple TRANSFORMs is a PITA. But I'm
>
>
> FWIW, I also wish we had something better than format() for this stuff. I
> did create [1] towards that end, but it currently depends on some C code,
> which is cumbersome.
For the most party, I'm pretty thrilled with format(), though:
- I'll admit to being grumpy about the %1$s notation, but
2016-02-12 22:41 GMT+01:00 Jim Nasby :
> On 2/12/16 2:58 PM, Pavel Stehule wrote:
>
>>
>> So I think adding something like this needs to at least address
>> *how* SQL level access would work, *when* it's eventually implemented.
>>
>>
>&g
Hi
2016-02-24 10:48 GMT+01:00 Artur Zakirov :
On 21.02.2016 11:31, Pavel Stehule wrote:
>
>> Hi
>>
>> I am sending updated version - the changes are related to fix comments.
>>
>>
> Great.
>
> I am new in reviewing, I think Pavel took into account
101 - 200 of 5142 matches
Mail list logo
