current scope has been scaled back to
just trying to get the syntax and on-disk structure right, then finish
off the implementation. See
http://wiki.postgresql.org/wiki/Table_partitioning to get an idea how
that's been broken into those two major chunks.
Anyway thanks for all of you
First of all, I really appreciate you gave me change to participate on
GSoC. It's great chance for me.
For this summer I have plan to make patch inplementing snapshot
materialized views (MV). I believe it will not be end of effort to
implement more of MV. But I / we need discuss MV syntax and
Dne 8.7.2010 12:33, Robert Haas napsal(a):
2010/6/29 Pavel Baroš:
Yeah, it is my fault, I did not mentioned that this patch is not final. It
is only small part of whole implementation. I wanted to show just this,
because I think that is the part that should not change much. And to show I
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
essage='NAZDAR'; end; $$;
ERROR: RAISE option already specified: MESSAGE
CONTEXT: PL/pgSQL function inline_code_block line 1 at RAISE
postgres=#
What do you think?
Pavel
>
> For the code with my patches on top on I ran the PL/Python tests for
> 2.4, 2.5, 2.6, 2.7 and 3.5. Everythin
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
>&
ssues:
1. Missing the possibility to pass custom data from SetRoleCheck_hook to
SetRoleAssign_hook. Tom mentioned it in his comment.
2. Missing little bit more comments and an explanation why and when to use
these hooks.
Regards
Pavel
>
> Joe
>
> --
> Crunchy Data - http://cru
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
t be used later while your
> temporary object still exists? I think making this work would make
> parallel query look like a minor feature.
>
The global temp tables can decrease these issues. Only few informations
should be private - and can be accessed via extra function call. Almost all
informa
ave not to use catalogue (when you use catalogue,
then you have bloating). But these special information are related mostly
to planner and should not be MVCC (number of pages, rows, statistics), and
because we are talking about temp tables, you can use session memory.
Regards
Pavel
&g
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
t from non array
value.
Today I did work on this patch and I am able to implement the syntax
proposed by you. It is proprietary, but similar to ADA anonymous types.
DECLARE x array() of type
Regards
Pavel
>
> (not necessary that syntax)
>
> then
>
> DECLARE
> var ELEMENT OF othervar%TYPE;
>
> should just fall into place.
>
>
Hi
We have not autocomplete for casting introduced by symbol "::". A
implementation should not be hard.
Regards
Pavel
t;
> (not necessary that syntax)
>
> then
>
> DECLARE
> var ELEMENT OF othervar%TYPE;
>
> should just fall into place.
>
>
I am sending update of this patch. The basic concept is same, syntax was
changed per your and Robert requirement.
Regards
Pavel
diff --git a/doc/s
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
ect pg_temp.tcl_eval($$
set list [lindex $::errorCode 0];
--- 567,575
("eval" body line 1)
invoked from within
"eval $1"
! (procedure "__PLTcl_proc_16841" line 3) <<<<<====
_PLTcl_proc_
invoked from wit
↵
0 ↵
filename ↵
pl_exec.c ↵
lineno ↵
3165 ↵
funcname ↵
exec_stmt_raise
(1 row)
I miss a SQLSTATE.
Why is used List object instead dictionary? TCL supports it
https://www.tcl.tk/man/tcl8.5/tutorial/Tcl23a.html
Regards
Pavel
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
s simplicity.
>
exactly - I would to decrease dependency on PostgreSQL internals. Working
with clean content is simple and possible with any environment without
unclean operations.
Regards
Pavel
>
> [1]
>
> http://www.postgresql.org/message-id/038517CEB6DE43BD8422D7947B6BE8D8@fanlij
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
ifference. Buy I have not information about your
input (octet or hex). I have the original string of SQL identifier inside
parser, executor, but I have not original string of function parameter
inside function (not without pretty complex and long code).
I am trying describe it in doc (I am
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
>
> -+
act on PL functions that try to repeated check of
pg_stat_activity. But this use case is not frequent.
Thank you.
Regards
Pavel
> regards, tom lane
>
;m sympathetic to that request. That seems like poor error
> checking and nothing else.
>
> (But note that I do not rule here.)
>
I am not sure, but maybe this issue is covered by plpgsql_check. But not
possible to check it when dynamic SQL is used.
Pavel
>
> --
> Rob
, I'm not especially opposed
> to that. I just think it needs a consensus that I haven't seen
> emerge.
>
This proposal is not bad from my perspective - but in detail these points
breaks compatibility, can have negative performance impacts or are ugly. I
understand to all points,
too shortcuts does the
languages dirty. In this point we have different opinion.
I proposed some enhanced PLpgSQL API with a possibility to create a
extension that can enforce your requested behave. The implementation can
not be hard, and it can coverage some special/individual requests well.
Regards
Pavel
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
re. COPY RAW, COPY BINARY tests well shares infrastructure.
>
> Review complete and passed. I can re-review if we want to add the
> additional test.
>
>
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. The nice feature (but not for this release)
can be additional cast info for import -- like "COPY table(jsonb_column)
FROM stdin (FORMAT RAW, CAST json_2_jsonb). Because there are the options,
there are big space for other enhancing.
Regards
Pavel
w is not 100% equal to ANSI SQL PIVOT clause. The ANSI SQL
command is much more rigid (it is one stage statement with predefined
columns), so argument of duplicate implementation one things is not valid.
Probably we would not implement non ANSI SQL feature on server.
Regards
Pavel
>
> Now,
detail in this moment. I can live with functional syntax too. The
functional syntax is easy parserable, but the SQL is not functional - so I
see it foreign there.
Where you are expecting the implementation? In PLpgSQL only, or generally
in DDL, or in both levels?
Regards
Pavel
>
> regards, tom lane
>
ed oid too.
>>
> Edited a bit + fix some typos and remove unneeded headers, patch attached
>
> Sorry, I can't find all corner-cases at once, but:
> SELECT parse_ident(E'"c".X XX');
> ERROR: identifier contains disallowed characters: "\"c&
imes by this. Some of them, such as UNIQUE, TEMPORARY and
> CONCURRENTLY are treated but they just doubles the matching
> condition expressions.
>
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 w
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
ot;c"
>
> Error message wrongly points to the reason of error.
>
>
I forgot my original plan - show full original string. Now, complete
original parameter is used as part of message everywhere. It is more
consistent.
I cannot to reuse escape_json - it escape double quotes, and t
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)
>> >>
&
e extended later if we think of other type operators we want.
>
> +1
>
> Anyone want to argue against changing the status of this to Rejected or
> at least Returned with feedback?
>
I would to reduce this patch to fix row type issue. There is not any
disagreement. I'll send r
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
> Dean, Tom, Peter, what do you think of the new version?
>
> Is anyone up for re-reviewing this? If not, I think we're going to
> have to reject this for lack of interest.
>
Can I do review?
Pavel
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
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
Thank you!
>
great, important feature
Thank you
Pavel
> --
> Vik Fearing +33 6 46 75 15 36
> http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@
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
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
the result in a variable (for example passing to
> volatile function). Take a look at the errhint() clause below -- we
> don't even have a suggestion in that case.
>
> This has come up before, and there was a fair amount of sympathy for
> this argument albeit with some dissent -
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 :-).
> >>
> >>
. worked
> too.
>
We are support
var := (query expression)
and this syntax is required and supported by ANSI/SQL - there are no any
reason to support other proprietary extension.
Regards
Pavel
>
> I'm not sure what other databases do is relevant. They use other
>> pr
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
QUERY PLAN
══
Aggregate (cost=179053.25..179053.26 rows=1 width=32)
-> Seq Scan on foo2 (cost=0.00..154053.60 rows=860 width=12)
(2 rows)
Regards
Pavel
p.s. It great step forward - it looks pretty well
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
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
l is nice feature. And should be pretty
nice, if we support more common formats - like csv, simple xml, simple
json. I believe so sometime the redundancy is acceptable, if the cost is
not too high.
sorry for offtopic - I would to see some output format on client side, but
the format possibilities are o
Hi
2016-03-29 8:43 GMT+02:00 Kyotaro HORIGUCHI :
> Thank you Pavel, David.
>
> Thank you for pointing syntaxes to be addressed. Most of the are
> addressed in the attached patch.
>
>
> At Tue, 22 Mar 2016 12:57:27 -0400, David Steele
> wrote in <56f17977.8040...@pg
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
ue - I don't know if it is solvable. Autocomplete
is working only for "if" keyword. When I am writing "if " or "if " or "if
exi" - then autocomplete doesn't work. But this issue is exactly same for
other "multi words" completation li
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
or that.
>
> What I am asking is to make PG aware of "previously used bind values",
> so it would calculate proper selectivities for $1, $2.
>
the implementation is simply - but it hard to design some really general -
it is task for UI
Pavel
>
> PS. It is not
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
>
if cost of generic plan is less than some MAGIC CONSTANT
(can be specified by GUC), then use generic plan. Elsewhere use a custom
plan everytime.
It allow to controll the plan reusing. When MAGIC CONSTANT = 0 .. use
custom plan everytime, When MAGIC CONSTANT = M, then use generic plan
always.
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
cases and it doesn't block any
other enhancing. There is still 1/3 of queries - too complex (slow
planning) too dynamic plan (the generic plan doesn't work).
Regards
Pavel
>
> Vladimir
>
y time" route, there is no way you
> introduce plan caching there.
>
I am sorry, I disagree. Albe's proposal should be compatible with current
state, so your argument is too strong. Default is same.
Pavel
>
> [1]: https://en.wikipedia.org/wiki/Anna_Karenina_principle
>
> Vladimir
>
ing useful
> syntax that I can think of.
>
Now I am able to write more correct argument. It is one from basic SQL
statement, and for using proprietary syntax should be pretty strong reason.
Probably there is less risk than 7 years ago, but still creating own syntax
isn't the best idea. T
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
is, but I think the tests are now
> worse than they were before.
>
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
sense from my opinion, and any hasn't significant advantage against other.
Regards
Pavel
>
>
> .m
>
> >Group Key: (a % 100)
> >-> Seq Scan on ab (cost=0.00..19853.00 rows=100 width=32)
> (actual
> > time=0.025..481.332 rows=100 loops=1)
> > Planning time: 0.164 ms
> > Execution time: 263288.332 ms
>
> Well, that's prett
used notation is only in direction
type->array. The working with symbols looks more difficult, than using
words (in design area).
More - the textual form is more near to our system of polymorphics types:
anyelement, anyarray, ... We have not anyelement[]
Regards
Pavel
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
in the first place.
>
> However I have no idea how feasible that is.
>
for statements like INSERT INTO tab VALUES(..), UPDATE tab SET x = WHERE id
= .. will be planner significant overhead. But these statements are
relative simply and probably some solution is exists.
Regards
Pavel
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
lues('aaa');
> INSERT 0 1
> test=# select あいう from t2;
> あいう
>
> aaa
> (1 row)
>
format uses same routine as quote_ident. So quote_ident should be fixed
first.
Regards
Pavel
>
> Best regards,
> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
> E
use can handle a raw C string. That desire might
> sound silly to a lot of -hackers, but given the amount of pain I went
> through figuring out how to properly marshal an ndarray back and forth in
> C, I sure as hell wish I could have done it in python! Since plpythonu
> understands bytea, I
ent[0] >= 'a' && ident[0] <= 'z') || ident[0] == '_');
> + safe = ((ident[0] >= 'a' && ident[0] <= 'z') || ident[0] == '_' ||
> IS_HIGHBIT_SET(ident[0]));
>
> for (ptr = ident; *ptr; ptr++)
> {
> @@ -9413,7 +9413,8 @@ quote_identifier(const char *ident)
>
> if ((ch >= 'a' && ch <= 'z') ||
> (ch >= '0' && ch <= '9') ||
> - (ch == '_'))
> + (ch == '_') ||
> + (IS_HIGHBIT_SET(ch)))
> {
> /* okay */
> }
>
>
This patch ls simply - I remember I was surprised, so we allow any
multibyte char few months ago.
+1
Pavel
gt; >> IS_HIGHBIT_SET(ident[0]));
> >>
> >> for (ptr = ident; *ptr; ptr++)
> >> {
> >> @@ -9413,7 +9413,8 @@ quote_identifier(const char *ident)
> >>
> >> if ((ch >= 'a' && ch <= 'z') ||
> >> (ch >= '0' && ch <= '9') ||
> >> - (ch == '_'))
> >> + (ch == '_') ||
> >> + (IS_HIGHBIT_SET(ch)))
> >> {
> >> /* okay */
> >> }
> >>
> >>
> > This patch ls simply - I remember I was surprised, so we allow any
> > multibyte char few months ago.
> >
> > +1
>
> If we would go this way, question is if we should back patch this or
> not since the patch apparently changes the existing
> behaviors. Comments? I would think we should not.
>
I am sure, so we should not backport this change. This can breaks customer
regress tests - and the current behave isn't 100% correct, but it is safe.
Pavel
>
> Best regards,
> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
> English: http://www.sraoss.co.jp/index_en.php
> Japanese:http://www.sraoss.co.jp
>
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
pening with these patches, or? They've been
> > inactive for quite a while now.
>
> Well, they are waiting for someone to review them.
>
I read some basic materials about systemd and these patche looks correct.
Next week I'll test it.
Regards
Pavel
>
>
>
>
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
; "characters" though. Also, the errdetail is conveying no actual extra
> detail AFAICS. I'd go with something like
>
> errmsg("identifier contains disallowed characters: \"%s\"",
> text_to_cstring(qual
s:
1. maybe we can decrease name to shorter "crossview" ?? I am happy with
crosstabview too, just crossview is correct too, and shorter
2. Columns used for ordering should not be displayed by default. I can live
with current behave, but hiding ordering columns is much more practical fo
1 - 100 of 5264 matches
Mail list logo
