On Thu, Jul 5, 2012 at 2:38 AM, Robert Haas robertmh...@gmail.com 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
On Thu, Jul 5, 2012 at 3:15 AM, Joel Jacobson j...@trustly.com wrote:
On Thu, Jul 5, 2012 at 2:38 AM, Robert Haas robertmh...@gmail.com 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.
On Tue, Jun 26, 2012 at 10:50 PM, Kohei KaiGai kai...@kaigai.gr.jp 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
On Mon, Jun 18, 2012 at 5:45 PM, Josh Kupershmidt schmi...@gmail.com wrote:
On Mon, Jun 18, 2012 at 3:56 AM, Dean Rasheed dean.a.rash...@gmail.com
wrote:
On 18 June 2012 04:21, Josh Kupershmidt schmi...@gmail.com wrote:
As a side note unrelated to this patch, I also dislike how function
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 Thu, Jul 5, 2012 at 4:04 AM, Gurjeet Singh singh.gurj...@gmail.comwrote:
On Thu, Jul 5, 2012 at 3:15 AM, Joel Jacobson j...@trustly.com wrote:
On Thu, Jul 5, 2012 at 2:38 AM, Robert Haas robertmh...@gmail.comwrote:
My vote is - when there's an overloaded function, put each version in
its
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 definition per
On Thu, Jul 5, 2012 at 3:32 PM, Michael Glaesemann g...@seespotcode.netwrote:
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
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
Joel Jacobson j...@trustly.com 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.
On Thu, Jul 5, 2012 at 4:46 PM, Tom Lane t...@sss.pgh.pa.us 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
Excerpts from Tom Lane's message of jue jul 05 10:46:52 -0400 2012:
Joel Jacobson j...@trustly.com 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
On Thu, Jul 5, 2012 at 5:17 PM, Alvaro Herrera
alvhe...@commandprompt.comwrote:
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
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 j...@trustly.com 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
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 that perform
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
Alvaro Herrera alvhe...@commandprompt.com 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.
On Thu, Jul 5, 2012 at 5:59 PM, Tom Lane t...@sss.pgh.pa.us 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
Joel Jacobson j...@trustly.com writes:
On Thu, Jul 5, 2012 at 4:46 PM, Tom Lane t...@sss.pgh.pa.us 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
On Thu, Jul 5, 2012 at 11:59 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@commandprompt.com 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
On Wed, Jul 4, 2012 at 1:56 PM, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Robert Haas robertmh...@gmail.com 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
-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
On Thu, Jul 5, 2012 at 6:09 PM, Tom Lane t...@sss.pgh.pa.us 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
Ronan Dunklau rdunk...@gmail.com 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
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 you
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 name
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 definition
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
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
On Wed, Jul 4, 2012 at 4:24 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2012/7/4 Robert Haas robertmh...@gmail.com:
On Tue, Jul 3, 2012 at 12:46 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
My point is that it seems like a bug that the secContext gets restored
in one case and not the other,
On Thu, Jul 5, 2012 at 12:57 PM, David E. Wheeler da...@justatheory.com 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
On Fri, Jul 6, 2012 at 2:01 AM, Tom Lane t...@sss.pgh.pa.us 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
Fujii Masao masao.fu...@gmail.com writes:
On Fri, Jul 6, 2012 at 2:01 AM, Tom Lane t...@sss.pgh.pa.us 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
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
Joel Jacobson j...@trustly.com 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
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 johnlumby(at)hotmail(dot)com
wrote:
An INSERT which has a RETURNING clause and which is to be rewritten
based on
a rule will
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 j...@trustly.com javascript:; writes:
New version, made a typo in last one.
I'm not particularly happy with
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
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
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:
Joel Jacobson j...@trustly.com 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
Roger that. I'm on it.
On Thursday, July 5, 2012, Tom Lane wrote:
Joel Jacobson j...@trustly.com javascript:; 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
On 05.07.2012 23:31, Tom Lane wrote:
Heikki Linnakangasheikki.linnakan...@iki.fi 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
On 05/07/12 22:37, Heikki Linnakangas wrote:
On 05.07.2012 23:31, Tom Lane wrote:
Heikki Linnakangasheikki.linnakan...@iki.fi 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,
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
Alvaro Herrera alvhe...@commandprompt.com 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
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
On Thu, Jul 5, 2012 at 5:52 PM, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Alvaro Herrera alvhe...@commandprompt.com 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
Christopher Browne cbbro...@gmail.com writes:
On Thu, Jul 5, 2012 at 5:52 PM, Dimitri Fontaine dimi...@2ndquadrant.fr
wrote:
Tom Lane t...@sss.pgh.pa.us writes:
FWIW, I'm attracted to the all-similarly-named-functions-together
method, mainly because it dodges the problem of how to encode a
Robert Haas robertmh...@gmail.com writes:
On Sun, Jul 1, 2012 at 5:11 AM, Alexander Korotkov aekorot...@gmail.com
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
Tatsuo Ishii is...@postgresql.org 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
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
On Thu, Jul 5, 2012 at 7:11 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sun, Jul 1, 2012 at 5:11 AM, Alexander Korotkov aekorot...@gmail.com
wrote:
[ new patch ]
With the improved comments in pg_wchar.h, it seemed clear what needed
to be done here,
Robert Haas robertmh...@gmail.com writes:
On Thu, Jul 5, 2012 at 7:11 PM, Tom Lane t...@sss.pgh.pa.us 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
Tatsuo Ishii is...@postgresql.org 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
On Mon, Jul 2, 2012 at 1:13 AM, Pavel Stehule pavel.steh...@gmail.com 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,
On Tue, Jul 3, 2012 at 2:59 AM, Kyotaro HORIGUCHI
horiguchi.kyot...@lab.ntt.co.jp 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
-
On Thu, Jul 5, 2012 at 5:31 PM, Dimitri Fontaine dimi...@2ndquadrant.fr 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.
On Thu, Jul 5, 2012 at 8:46 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Jul 5, 2012 at 7:11 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Hm, several of these routines seem to neglect to advance the from
pointer?
Err... yeah. That's not a bug I
2012/7/6 Josh Kupershmidt schmi...@gmail.com:
On Mon, Jul 2, 2012 at 1:13 AM, Pavel Stehule pavel.steh...@gmail.com 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
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 pe...@2ndquadrant.com:
On 2 July 2012 15:19, Peter
61 matches
Mail list logo
