Hello,
> > I've been stuck in mud trying to plperl work on windows
> > environment. I saw many messages complaining that plperl wouldn't
> > be built to work. For the convenience of those and myself, I
> > describe the process of building postgresql with plperl on
> > Windows with cygwin and VC++
Hello
* fixed typo
* support two new fields: constraint_table and trigger_table
* routine_table, routine_schema, trigger_name, trigger_table,
trigger_schema has value when exception coming from plpgsql.
Regards
Pavel
2012/7/2 Peter Geoghegan :
> On 2 July 2012 15:19, Peter Geoghegan wrote:
>>
2012/7/6 Josh Kupershmidt :
> On Mon, Jul 2, 2012 at 1:13 AM, Pavel Stehule wrote:
>
>> I tested Peter's patch and it works well.
>
> I liked it as well. But I'm not sure what should happen with the patch
> now. It seems like it'd be commit-ready with just a tweak or two to
> the query as I noted
On Thu, Jul 5, 2012 at 8:46 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jul 5, 2012 at 7:11 PM, Tom Lane wrote:
>>> Hm, several of these routines seem to neglect to advance the "from"
>>> pointer?
>
>> Err... yeah. That's not a bug I introduced, but I should have caught
>> it... and it
On Thu, Jul 5, 2012 at 5:31 PM, Dimitri Fontaine wrote:
> [ new patch ]
Attached is a incremental patch with a bunch of minor cleanups,
including reverts of a few spurious white space changes. Could you
merge this into your version?
I have some concerns about pg_dump:
1. Can we spell out EvtTr
On Tue, Jul 3, 2012 at 2:59 AM, Kyotaro HORIGUCHI
wrote:
> Hello, Here is regression test runs on pg's also built with
> cygwin-gcc and VC++.
Thank you!
> The patches attached following,
>
> - plperl_sql_ascii-4.patch : fix for pl/perl utf8 vs sql_ascii
> - plperl_sql_ascii_regress-1.pat
On Mon, Jul 2, 2012 at 1:13 AM, Pavel Stehule wrote:
> I tested Peter's patch and it works well.
I liked it as well. But I'm not sure what should happen with the patch
now. It seems like it'd be commit-ready with just a tweak or two to
the query as I noted in my last mail, but Tom did seem oppos
> Tatsuo Ishii writes:
>>> So far as I can see, the only LCPRVn marker code that is actually in
>>> use right now is 0x9d --- there are no instances of 9a, 9b, or 9c
>>> that I can find.
>>>
>>> I also read in the xemacs internals doc, at
>>> http://www.xemacs.org/Documentation/21.5/html/internal
Robert Haas writes:
> On Thu, Jul 5, 2012 at 7:11 PM, Tom Lane wrote:
>> Hm, several of these routines seem to neglect to advance the "from"
>> pointer?
> Err... yeah. That's not a bug I introduced, but I should have caught
> it... and it does make me wonder how well this code was tested.
> Do
On Thu, Jul 5, 2012 at 7:11 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Jul 1, 2012 at 5:11 AM, Alexander Korotkov
>> wrote:
>>> [ new patch ]
>
>> With the improved comments in pg_wchar.h, it seemed clear what needed
>> to be done here, so I fixed up the MULE conversion and committed
On Thu, Jul 05, 2012 at 10:10:08PM +0200, Antonin Houska wrote:
> I found out by chance that \copyright command still contains 2011.
> Perhaps documentation of "new year's day changes" needs to be
> updated, if such exists.
What version of Postgres is this? We don't update the copyright for
minor
Tatsuo Ishii writes:
>> So far as I can see, the only LCPRVn marker code that is actually in
>> use right now is 0x9d --- there are no instances of 9a, 9b, or 9c
>> that I can find.
>>
>> I also read in the xemacs internals doc, at
>> http://www.xemacs.org/Documentation/21.5/html/internals_26.htm
Robert Haas writes:
> On Sun, Jul 1, 2012 at 5:11 AM, Alexander Korotkov
> wrote:
>> [ new patch ]
> With the improved comments in pg_wchar.h, it seemed clear what needed
> to be done here, so I fixed up the MULE conversion and committed this.
> I'd appreciate it if someone would check my work
Christopher Browne writes:
> On Thu, Jul 5, 2012 at 5:52 PM, Dimitri Fontaine
> wrote:
>> Tom Lane writes:
>>> FWIW, I'm attracted to the all-similarly-named-functions-together
>>> method, mainly because it dodges the problem of how to encode a
>>> function's argument list into a filename. How
On Thu, Jul 5, 2012 at 5:52 PM, Dimitri Fontaine wrote:
> Alvaro Herrera writes:
>> However I am also against what seems to be the flow. Normally, you
>> don't write overloaded plpgsql functions such as "equal". Case in
>> point, the equality functions in core have funny names like "int4eq" and
On 05/07/12 23:30, Peter Eisentraut wrote:
On tor, 2012-07-05 at 22:53 +0200, Jan Urbański wrote:
The problem is that PLyUnicode_Bytes is (via an ifdef) used as
PyString_ToString on Python3, which means that there are numerous call
sites and new ones might appear in any moment. I'm not that keen
Alvaro Herrera writes:
> However I am also against what seems to be the flow. Normally, you
> don't write overloaded plpgsql functions such as "equal". Case in
> point, the equality functions in core have funny names like "int4eq" and
> so on. Instead, at least in my experience, the overloaded
On tor, 2012-07-05 at 22:53 +0200, Jan Urbański wrote:
> The problem is that PLyUnicode_Bytes is (via an ifdef) used as
> PyString_ToString on Python3, which means that there are numerous call
> sites and new ones might appear in any moment. I'm not that keen on
> invoking the traceback machinery
On 05/07/12 22:37, Heikki Linnakangas wrote:
On 05.07.2012 23:31, Tom Lane wrote:
Heikki Linnakangas writes:
Fix mapping of PostgreSQL encodings to Python encodings.
The buildfarm doesn't like this --- did you check for side effects on
regression test results?
Hmm, I ran the regressions tes
On 05.07.2012 23:31, Tom Lane wrote:
Heikki Linnakangas writes:
Fix mapping of PostgreSQL encodings to Python encodings.
The buildfarm doesn't like this --- did you check for side effects on
regression test results?
Hmm, I ran the regressions tests, but not with C encoding. With the
patch,
Roger that. I'm on it.
On Thursday, July 5, 2012, Tom Lane wrote:
> Joel Jacobson > writes:
> You may in fact need a new field --- I'm just saying it should be in the
> object-type-specific struct, eg FuncInfo, not DumpableObject.
>
> regards, tom lane
>
Joel Jacobson writes:
> I agree, good suggestion, I just didn't know how to implement it without a
> new field. I'll make a new attempt to get it right.
You may in fact need a new field --- I'm just saying it should be in the
object-type-specific struct, eg FuncInfo, not DumpableObject.
I found out by chance that \copyright command still contains 2011.
Perhaps documentation of "new year's day changes" needs to be updated,
if such exists.
Tony H.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.or
On 05/07/12 21:37, Heikki Linnakangas wrote:
Committed. This bug was present in versions >= 9.0, so backpatched.
Thanks!
I used ereport() rather than elog() in the error message. Correct me if
that was wrong, but the point was to avoid PLy_elog(), because that
might cause recursion, and erepo
On 04.07.2012 15:11, Jan Urbański wrote:
On 04/07/12 13:58, Asif Naeem wrote:
I have test the patch on Win64. postgres server is working fine now for
WIN1252. Thanks.
create function enctest() returns text as $$
return b'tr\xc3\xb3spido'.decode('**utf-8')
$$ language plpython3u;
select enctes
I agree, good suggestion, I just didn't know how to implement it without a
new field. I'll make a new attempt to get it right.
On Thursday, July 5, 2012, Tom Lane wrote:
> Joel Jacobson > writes:
> > New version, made a typo in last one.
>
> I'm not particularly happy with the idea of adding a so
First, apologies for taking so long to reply to your post.
On Fri, 22 Jun 2012 09:55:13, Robert Haas wrote:
> On Wed, Jun 20, 2012 at 12:24 PM, John Lumby
> wrote:
> > An INSERT which has a RETURNING clause and which is to be rewritten
> >based on
> > a rule will be accepted if the r
Joel Jacobson writes:
> New version, made a typo in last one.
I'm not particularly happy with the idea of adding a sortkey field to
DumpableObject as such, when most object types don't need it. That just
bloats the code and pg_dump's memory consumption. It would be better to
modify the already-
> I'd rather have the few overloaded-functions in one file (hopefully
> with deterministic ordering) and a sane, simple filename, than have
> every function in every database in a separate file with some strange
> mess in the filename that makes me cringe every time I see it.
Having tried it both
Fujii Masao writes:
> On Fri, Jul 6, 2012 at 2:01 AM, Tom Lane wrote:
>> I will go ahead and remove that code.
> Thanks!
> BTW, I was just implementing the patch ;) Patch attached.
Oh, I'd already done it when I got your message :-(. Looks like we
arrived at the same answers, though, except f
On Fri, Jul 6, 2012 at 2:01 AM, Tom Lane wrote:
> I wrote:
>> I agree, let's drop the support for waitpid() not being present.
>
> BTW, some digging in the commit logs shows that postmaster.c's
> existing support for using wait3 in place of waitpid was added in
> commit a5494a2d92a2752c610b8b668a7
On Thu, Jul 5, 2012 at 12:57 PM, David E. Wheeler wrote:
> On Jul 5, 2012, at 3:21 PM, Andrew Dunstan wrote:
>
>> No they are not necessarily one logical unit. You could have a bunch of
>> functions called, say, "equal" which have pretty much nothing to do with
>> each other, since they refer to d
On Wed, Jul 4, 2012 at 4:24 PM, Kohei KaiGai wrote:
> 2012/7/4 Robert Haas :
>> On Tue, Jul 3, 2012 at 12:46 PM, Kohei KaiGai wrote:
My point is that it seems like a bug that the secContext gets restored
in one case and not the other, depending on which user ID was specified
in SET
Excerpts from Alvaro Herrera's message of vie jun 29 19:17:02 -0400 2012:
> I was only testing migrating from an old version into patched, not
> same-version upgrades.
>
> I think I see what's happening here.
Okay, I have pushed the fix to github -- as I suspected, code-wise the
fix was simple.
I wrote:
> I agree, let's drop the support for waitpid() not being present.
BTW, some digging in the commit logs shows that postmaster.c's
existing support for using wait3 in place of waitpid was added in
commit a5494a2d92a2752c610b8b668a7d33478e90c160, "Various patches for
nextstep by GregorHoffl
On Jul 5, 2012, at 3:21 PM, Andrew Dunstan wrote:
> No they are not necessarily one logical unit. You could have a bunch of
> functions called, say, "equal" which have pretty much nothing to do with
> each other, since they refer to different types.
>
> +1 from me for putting one function definit
Hello
there is a updated patch:
* renamed auxiliary functions and moved it elog.c - header is new file
"relerror.h"
* new fields "constraint_table" and "trigger_table" - constraints and
triggers are related to relation in pg, not just to schema
* removed using implicit constraints without unique
Excerpts from Christopher Browne's message of jue jul 05 12:10:09 -0400 2012:
> I wound up expanding the function arguments and using function + args
> as the name. That leads to a risk of rather long names for functions,
> but there aren't many other ways possible.
Well, maybe not many, but yo
Ronan Dunklau writes:
> Let's say I have an IMAP foreign data wrapper, and I write a query
> joining the table on itself using the In-Reply-To and Message-ID
> headers, is there anything I can do to avoid fetching all the mails
> from the remote server ?
> If I could somehow inform the planner th
On Thu, Jul 5, 2012 at 6:09 PM, Tom Lane wrote:
> Well, to be perfectly frank, I already doubt that this entire feature
> passes the complexity-versus-value test, because pg_dump is not a
> substitute for an SCM --- people who have got enough functions to need
> this sort of thing need to be keep
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello.
I'm in the process of porting our multicorn extension to pg9.2, and
I'd like to take advantage of the GetForeignPaths hook.
The multicorn extension allows the creation of a FDW in python using a
simple API, and I'd like to be able to provide F
On Wed, Jul 4, 2012 at 1:56 PM, Dimitri Fontaine wrote:
> Dimitri Fontaine writes:
>> Robert Haas writes:
>>> No, I'm not asking you to add any more columns right now (in fact,
>>> please do not). But the type of the existing column should change to
>>> text[].
>>
>> Ok, done in the attached. W
On Thu, Jul 5, 2012 at 11:59 AM, Tom Lane wrote:
> Alvaro Herrera writes:
>> Excerpts from Michael Glaesemann's message of jue jul 05 11:36:51 -0400 2012:
>>> If we're dumping objects (tables, views, functions, what-have-you) into
>>> separate files,
>>> each of these functions is a separate obj
Joel Jacobson writes:
> On Thu, Jul 5, 2012 at 4:46 PM, Tom Lane wrote:
>> pg_dump is already a bloated, nearly unmaintainable mess. The very
>> last thing it needs is even more options.
> If you are referring to the code, I don't think that's a good argument
> against implementing new good fea
On Thu, Jul 5, 2012 at 5:59 PM, Tom Lane wrote:
> FWIW, I'm attracted to the all-similarly-named-functions-together
> method, mainly because it dodges the problem of how to encode a
> function's argument list into a filename. However, we're being
> short-sighted to only think of functions here.
Alvaro Herrera writes:
> Excerpts from Michael Glaesemann's message of jue jul 05 11:36:51 -0400 2012:
>> If we're dumping objects (tables, views, functions, what-have-you) into
>> separate files,
>> each of these functions is a separate object and should be in its own file.
> Clearly there is n
On Jul 5, 2012, at 11:52, Alvaro Herrera wrote:
> Isn't this a perfect example of stuff that, since it does much the same
> thing, should be in the same file so that you remember to fix them all
> together if you find a bug in one?
That's what tests are for.
Michael Glaesemann
grzm seespotcode
Excerpts from Michael Glaesemann's message of jue jul 05 11:36:51 -0400 2012:
>
> On Jul 5, 2012, at 11:17, Alvaro Herrera wrote:
> > However I am also against what seems to be the flow. Normally, you
> > don't write overloaded plpgsql functions such as "equal".
>
> I often write functions tha
On Jul 5, 2012, at 11:17, Alvaro Herrera wrote:
>
> Excerpts from Tom Lane's message of jue jul 05 10:46:52 -0400 2012:
>> Joel Jacobson writes:
>>> Maybe it could be made an option to pg_dump?
>>
>> Ick. Then we have to deal with all the downsides of *both* methods.
>>
>> pg_dump is already
On Thu, Jul 5, 2012 at 5:17 PM, Alvaro Herrera
wrote:
> Agreed.
>
> However I am also against what seems to be the flow. Normally, you
> don't write overloaded plpgsql functions such as "equal". Case in
> point, the equality functions in core have funny names like "int4eq" and
> so on. Instead,
Excerpts from Tom Lane's message of jue jul 05 10:46:52 -0400 2012:
> Joel Jacobson writes:
> > Maybe it could be made an option to pg_dump?
>
> Ick. Then we have to deal with all the downsides of *both* methods.
>
> pg_dump is already a bloated, nearly unmaintainable mess. The very
> last th
On Thu, Jul 5, 2012 at 4:46 PM, Tom Lane wrote:
> Ick. Then we have to deal with all the downsides of *both* methods.
>
> pg_dump is already a bloated, nearly unmaintainable mess. The very
> last thing it needs is even more options.
When you say bloated, are you referring to the code or the c
Joel Jacobson writes:
> Maybe it could be made an option to pg_dump?
Ick. Then we have to deal with all the downsides of *both* methods.
pg_dump is already a bloated, nearly unmaintainable mess. The very
last thing it needs is even more options.
regards, tom lane
--
Maybe it could be made an option to pg_dump?
Some users and their systems might not even have overloaded functions,
and these users will of course prefer a nice looking filename, i.e. all
functions
having the same name kept in the same file. Which for them will mean only
one function per file anyw
On Thu, Jul 5, 2012 at 3:32 PM, Michael Glaesemann wrote:
>
> On Jul 5, 2012, at 9:21, Andrew Dunstan wrote:
>
> > No they are not necessarily one logical unit. You could have a bunch of
> > functions called, say, "equal" which have pretty much nothing to do with
> > each other, since they refer t
On Jul 5, 2012, at 9:21, Andrew Dunstan wrote:
> No they are not necessarily one logical unit. You could have a bunch of
> functions called, say, "equal" which have pretty much nothing to do with
> each other, since they refer to different types.
>
> +1 from me for putting one function definitio
On Thu, Jul 5, 2012 at 4:04 AM, Gurjeet Singh wrote:
> On Thu, Jul 5, 2012 at 3:15 AM, Joel Jacobson wrote:
>
>> On Thu, Jul 5, 2012 at 2:38 AM, Robert Haas wrote:
>>
>>> My vote is - when there's an overloaded function, put each version in
>>> its own file. And name the files something like
>>>
New version, made a typo in last one.
pg_dump_deterministic_order_v3.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Jun 18, 2012 at 5:45 PM, Josh Kupershmidt wrote:
> On Mon, Jun 18, 2012 at 3:56 AM, Dean Rasheed
> wrote:
>> On 18 June 2012 04:21, Josh Kupershmidt wrote:
>
>>> As a side note unrelated to this patch, I also dislike how function
>>> name tab-completions will not fill in the opening par
On Tue, Jun 26, 2012 at 10:50 PM, Kohei KaiGai wrote:
> * Regarding to deparseSimpleSql(), it pulls attributes being referenced
> from baserestrictinfo and reltargetlist using pull_var_clause().
> Is it unavailable to use local_conds instead of baserestrictinfo?
> We can optimize ref
On Thu, Jul 5, 2012 at 3:15 AM, Joel Jacobson wrote:
> On Thu, Jul 5, 2012 at 2:38 AM, Robert Haas wrote:
>
>> My vote is - when there's an overloaded function, put each version in
>> its own file. And name the files something like
>> functionname_something.sql. And just document that somethin
On Thu, Jul 5, 2012 at 2:38 AM, Robert Haas wrote:
> My vote is - when there's an overloaded function, put each version in
> its own file. And name the files something like
> functionname_something.sql. And just document that something may not
> be entirely stable.
I would agree that's better
62 matches
Mail list logo
