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
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
the function "pg_size_bytes" handle "bytes" as a size unit
> (see p.III)?
> There was no disagreement, but if I saw that thread before I became a
> reviewer and saw silent approval I would have argued. Moreover
> supporting of negative sizes was explained[4] by a symm
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
Hi
2016-01-26 13:48 GMT+01:00 Vitaly Burovoy :
> Hello, Pavel!
>
> That letter was not a complain against you. I'm sorry if it seems like
> that for you.
>
ok.
It was an intermediate review with several points to be clear for _me_
> from experienced hackers, mos
ise rich PostgreSQL exception from Python.
With new function all available functionality related to PostgreSQL
exception can be used simply.
plpy.raise_warning("some doesn't work", detail = "user registration ... ")
This patch is reduced previous patch (no new featu
gt; So the visual hint that there are more characters at the end is lost.
>
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 (on
st.
> >>
> >
> > 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 iden
actly 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 ASCII white
chars. The current design is too simple - with
paces should be treated as ASCII white spaces?
>
I am not sure, if SQL standard say some about it. But I am sure, so using
unescaped or unclosed UTF8 spaces is bug, dangerous, wrong
Pavel
> Best regards,
> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
> English: http://www.sraoss.co.jp/index_en.php
> Japanese:http://www.sraoss.co.jp
>
ce",
"MESSAGE" : "CONTEXT: PL/pgSQL function inline_code_block line 1 at
RAISE"
}
Is it expected?
Second issue:
Mapping of levels between pg and journal levels is moved by1
+case DEBUG1:
+systemd_log_prefix = "<7>" /* SD_DEBUG */;
+break;
+case LOG:
+case COMMERROR:
+case INFO:
+systemd_log_prefix = "<6>" /* SD_INFO */;
+break;
+case NOTICE:
+case WARNING:
+systemd_log_prefix = "<5>" /* SD_NOTICE */;
+break;
+case ERROR:
+systemd_log_prefix = "<4>" /* SD_WARNING */;
+break;
+case FATAL:
+systemd_log_prefix = "<3>" /* SD_ERR */;
+break;
+case PANIC:
is it expected?
This is little bit unexpected - (can be correct).
When I use filtering "warnings", then I got errors, etc. I can understand
so these systems are not compatible, but these differences should be well
documented.
I didn't find any other issues. It is working without any problems.
Regards
Pavel
(buildin exceptions) and dynamic (custom exceptions). It cannot be mixed,
but there can be some abstract ancestor. Second solution is defensive -
using procedural API for custom exceptions - what i doing in PLPythonu.
Regards
Pavel
gt; > extern PLpgSQL_type *plpgsql_parse_wordrowtype(char *ident);
> > extern PLpgSQL_type *plpgsql_parse_cwordrowtype(List *idents);
> > extern PLpgSQL_type *plpgsql_build_datatype(Oid typeOid, int32 typmod,
>
> By the way, these functions are misnamed after this
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
ave hot-standby mode.
It doesn't work with only standby mode
[root@dhcppc1 pavel]# systemctl start pg2.service
Job for pg2.service failed because a timeout was exceeded. See "systemctl
status pg2.service" and "journalctl -xe" for details.
Default timeout on FC is 90 s
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
COPY
FROM, and any more calls can decrease performance. And then I have to do
these checks before calling.
Regards
Pavel
"ready" state for
standby only mode starting when slave is able to get wal records or
segments from server. I will test it next week.
regards
Pavel
> > Default timeout on FC is 90 sec - it is should not to be enough for
> > large servers with large shared buffers and high c
27;t like the separate Error being raised. I
> don't agree, but even if I would, it's not this patch's job to change
> that and Error is already raised today. This patch should be
> consistent with the status quo and therefore be similar to plpy.error.
> If Error is bad, it should be replaced by SPIError everywhere
> separately.
ok
The wrong is duality of Error and SPIError, because it is only one real
exception.
The correct naming for current situation are names: PoorError (message
only) and RichError (full set of Edata fields). This is strange from Pg
perspective and still is strange from Python view.
I agree, we should to unify a exception from (raise, elog) functions and
Error has little bit better sense for me. The disadvantage is redundant
code for filling and reading exception properties (I have to support
SPIError), but in this case it is less wrong than strange behave.
Regards
Pavel
>
> Next week I'll send a patch to improve the docs.
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
. I have not any open questions or notes, just would to recheck
final version.
Regards
Pavel
>
> Best regards,
> --
> Daniel Vérité
> PostgreSQL-powered mailer: http://www.manitou-mail.org
> Twitter: @DanielVerite
>
>
> --
> Sent via pgsql-hackers maili
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
(not only session)
* access and usage outside PL (from SQL)
Comments, notes??
Regards
Pavel
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
nterface can be based on get/set functions. We can do
necessary transformations there.
Regards
Pavel
s feature has only small relation to SQL PIVOTING feature - it is just
form of view and I am agree with Daniel about sense of this feature.
Regards
Pavel
>
> So please can we have that wiki page so that the syntax can be hammered
> out a bit more.
>
> I'm closing this as retu
form of view and I am agree with Daniel about sense of this feature.
>
> Yes, I don't disagree there. Robert Haas and David Fetter also
> expressed their support for psql-side processing, so I think we're good
> there.
>
>
great. Personally, I have not any objec
ew [colV] [colH]
[colG1[,colG2...]] [sortCol [asc|desc]] - when I would to enter sort order
column, I have to enter one or more colG1,... or I have to enter explicitly
asc, desc keyword.
Regards
Pavel
>
> Overall, I like the feature, but I'm not convinced that it
syntax is not unambiguous: \crosstabview [colV] [colH]
> > [colG1[,colG2...]] [sortCol [asc|desc]] - when I would to enter sort
> order
> > column, I have to enter one or more colG1,... or I have to enter
> explicitly
> > asc, desc keyword.
> >
>
> That is resolved by the comma that precedes colG2, etc. isn't it?
>
but colG1 is optional. What if you miss any colGx ?
Regards
Pavel
>
> Regards,
> Dean
>
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
y')
> as a ;
> length | length
> +
> 414 | 63
>
>
>
fixed - I used the function downcase_truncate_identi
be limited to number's or C locale sorting.
I don't think so full sort possibilities are necessary.
Regards
Pavel
> regards, tom lane
>
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
ch_path. With
search_path you have not any control over variable type, variable existence
- and there are possible lot of impacts on plan cache, behave. So I propose
SCHEMA VARIABLES with schema scope - and then search_path has zero effect
on the behave. It doesn't introduce new dependenc
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
I miss
extern living object, then I have to do validation all functions in schema
together. What is much more expensive. I don't would to introduce slower
Oracle compilations and dependency issues. So I need externally created
object. It was reason, why I used a statement CREATE instead statement
DECLARE.
Regards
Pavel
Regards
Pavel
Hi Vitaly,
please, can you send your version of this patch, how we talked about it in
Moscow?
Thank you
Pavel
f enums visible from user level. The work with it isn't too
much comfortable. If it will be required, then we have it. The original
implementation of this proposal was designed in exactly same style.
Regards
Pavel
static variables can be enough for 50%, but it is too limited.
Postgres cannot to pass and work with references, so this C design can be
too expensive.
Regards
Pavel
>
> --
> Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
> Experts in Analytics, Data Architecture and PostgreSQL
> Data in Trouble? Get it in Treble! http://BlueTreble.com
>
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
ink is
>> pretty important) you're only choice is to use SECDEF functions,
>> which is awkward at best.
>>
>
> While this patch doesn't need to implement SQL access to variables, I
> think the design needs to address it.
SQL access to variables needs a) chan
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
ated to human readable error messages. We can
move some code to separate static functions - read_quoted_ident,
read_unquoted_ident, but there will be some magic about parameters, and the
code will not be much better, than it is now.
>
> The new status of this patch is: Waiting on Author
&g
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,
, '2000-12-01', '1 month') d)
>
The idea is ok, but this design cannot be described as user friendly. The
work with time dimension is pretty common, and should be supported by some
short user friendly syntax.
Regards
Pavel
>
> Regards,
> Dean
>
ly a cleanup, but I think it's something we should do since it's only 2
> variables and 2 functions.
>
> AFAICT these are clearly meant to be internal. (the plugin variable is
> accessed through find_rendezvous_variable)
>
+1
Pavel
>
> Comments?
>
> --
&g
n table "foo".
> > SCHEMA NAME: public
> > TABLE NAME: bar
> > CONSTRAINT NAME: bar_f1_fkey
> > LOCATION: ri_ReportViolation, ri_triggers.c:3326
> > regression=#
>
> Wow, that's a fabulous idea. I see Oleksandr has tried to implement
> it, although I hav
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
;s
> obviously biased by my experience maintaining EDB's extensions, and
> other people may well feel differently. But to me, the update that's
> required here is no worse than what
> 5043193b78919a1bd144563aadc2f7f726549913 required, and I didn't hear
> any complaints
sting
https://github.com/orafce/orafce
https://github.com/orafce/orafce/commit/fff56ed7e17ed5d6f8e6b71591ff1a6d6ff12d79
With last commit I am able to compile orafce without warnings, but
installcheck is broken. It can be bug in orafce, but this code worked last
7 years.
Pavel
> Re
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
should not be executed from any SQL, because
SQL has not directly related schema. It can be executed only from SQL
embedded in some object with attached schema - PL functions, views,
constraints, .. So for this use case, the important information is info
about a container. We have to hold info a
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
spidata.
5. fields: message, detail and hint are implicitly translated to string -
it decrease a necessity of legacy mode
Curent version doesn't do:
1. touch plpy exception classes.
A doc should be enhanced, but the code should be +/- final.
Regards
Pavel
diff --git a/doc/src/sgml/plpython
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'
reSQL logs,
we working with log aggregators.
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.
Is this feature interesting for community? What do you think about it?
Regards
Pavel
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
be +/- same. But you will enforce
Numeric into outer expression evaluation.
The result will not be used together with function pg_size_pretty, but much
more with functions pg_relation_size, pg_relation_size, .. and these
functions doesn't return Numeric. These functions returns bigint. Bigi
> that is, the format string for errmsg(). This is not best but
> useful enough.
>
> It is somewhat a crude way, but the attached small patch would
> do.
>
> Is there any opinions or suggestions?
>
It looks like workaround. The fixing missing sqlerrcode is much better.
Reg
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
er distros seem to have similar problem
(https://launchpad.net/ubuntu/+source/libpgjava).
We will be thankful for any idea.
Pavel Kajaba
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Oh, Pavel probably forgot to CC pgjdbc, fixing.
Forwarded message from Craig Ringer:
On 16 February 2016 at 20:15, Pavel Kajaba wrote:
> Hello pg-hackers,
>
> I need advice about postgresql-jdbc driver.
>
> Current version in Fedora is behind
ity to miss 9.6 because of not registering it in time.
>
I'll do it. Now, I fixing 3.4 Python code. There are more issues with
"could not convert Python Unicode object to bytes"
Regards
Pavel
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
>> &
o be aware of when cleaning up the CF app entries.
>>
>
> I agree with Alvarro; this seems like a bug to me. If a patch is ready for
> committer in CF N, why would it suddenly not be ready in N+1?
>
+1,
This behave is pretty unpleasant and frustrating.
Regards
Pavel
> --
&g
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.
eels like we
> haven't nailed the design to something satisfactory. All the tests you
> needed to change are a hint towards that.
>
It not any problem. I am thankful for cooperation.
Regards
Pavel
diff --git a/doc/src/sgml/plpython.sgml b/doc/src/sgml/plpython.sgml
new f
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
t;
> % select
> parse_ident(E'X\rXX');
> XX""X
> Time: 0,510 ms
>
>
:(, .. I'll fix it today or tomorrow, when I'll have free time
Pavel
>
>
>
> --
> Teodor Sigaev
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
this name was related to syntax %TYPE. And because new
syntax allows more constructs, then the change name is correct. I am think.
But choosing names is hard work. The new name little bit more strongly show
relation to work with referenced types.
>
>
>>
> I noticed a little typo in
ck duration"
isn't printed to log.
Comments, notes?
Regards
Pavel
101 - 200 of 5264 matches
Mail list logo
