Hi.
Ummm, I present is not understood by the reason of Japanese. ...
Therefore, It was made into the Spanish case.
I know that Alvaro-san will understand Spanish well.
==postgresql.conf==
lc_messages= 'es'
server.log of a patch before and after was applied.
Please see it.
Regards,
On Fri, Mar 6, 2009 at 8:44 PM, Josh Berkus j...@agliodbs.com wrote:
Robert,
Thing is, anybody can institute their own naming convention. I've long used
v_ as a prefix. Allowing : would save me some keystrokes, but that's about
it.
--Josh
True... but there doesn't seem to be any shortage
It wouldn't be so bad if you could assign internal and external column names.
Within the function you call the column v_foo but the caller of the
function receives column foo instead.
OUT v_foo varchar AS foo
Another alternative is requiring a prefix like plout for the
replacement to occur:
(
I have a little php-script to help me learn foreign languages
In my php-code I have the following line:
$query=update wordlist set known=true where dutch='.$preceding.';
This worked fine on a system running postgres 8.1, however in version
8.3.5 something changed which makes records with the
On Sat, Mar 7, 2009 at 9:08 AM, Rod Taylor rod.tay...@gmail.com wrote:
It wouldn't be so bad if you could assign internal and external column names.
Within the function you call the column v_foo but the caller of the
function receives column foo instead.
OUT v_foo varchar AS foo
Another
Robert Haas robertmh...@gmail.com writes:
On Sat, Mar 7, 2009 at 9:08 AM, Rod Taylor rod.tay...@gmail.com wrote:
It wouldn't be so bad if you could assign internal and external column names.
This is a good point. Uglifying the parameter names is sort of OK for
input parameters, but is much
o...@pyrenet.fr writes:
the only thing I could come with is a calloc(1,12) that seems to alloc
mem for filename, in that case sdewitte.dmp; so the alloc is not counting
the null char at the end.
Where do you see that? The memtool dump you sent doesn't show it AFAICS.
2009/3/7 Robert Haas robertmh...@gmail.com:
On Sat, Mar 7, 2009 at 9:08 AM, Rod Taylor rod.tay...@gmail.com wrote:
It wouldn't be so bad if you could assign internal and external column names.
Within the function you call the column v_foo but the caller of the
function receives column foo
Tom Lane t...@sss.pgh.pa.us writes:
Robert Haas robertmh...@gmail.com writes:
On Sat, Mar 7, 2009 at 9:08 AM, Rod Taylor rod.tay...@gmail.com wrote:
It wouldn't be so bad if you could assign internal and external column
names.
This is a good point. Uglifying the parameter names is sort of
Gregory Stark st...@enterprisedb.com writes:
I'm not sure that's any better. The case where I've run into this is when I
have something like:
balance := new value
UPDATE tab SET balance = balance
In that case the only way we could get it right is if we default to the local
variable but
actually - function name should be used as label now. This code is working:
Not helpful for me. The most typical conflict I have is actually the
OUT parameter and table name, not a column of the table.
Really don't want to prefix all tables with a hardcoded schema or do
variable substitution
Hello
2009/3/7 Tom Lane t...@sss.pgh.pa.us:
Gregory Stark st...@enterprisedb.com writes:
I'm not sure that's any better. The case where I've run into this is when I
have something like:
balance := new value
UPDATE tab SET balance = balance
In that case the only way we could get it right
On Sat, Mar 7, 2009 at 11:32 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sat, Mar 7, 2009 at 9:08 AM, Rod Taylor rod.tay...@gmail.com wrote:
It wouldn't be so bad if you could assign internal and external column
names.
This is a good point. Uglifying
Hello
2009/3/7 Rod Taylor rod.tay...@gmail.com:
actually - function name should be used as label now. This code is working:
Not helpful for me. The most typical conflict I have is actually the
OUT parameter and table name, not a column of the table.
This conflict I never meet. And I afraid
Currently, load_hba() bails on the first parsing error. It would be
better for the typo-prone sysadmin if it reported ALL errors, and THEN
bailed out.
This patch implements that behavior. Tested against 8.4 HEAD this morning.
Idea is to do a similar thing for postgresql.conf. That is a
Selena Deckelmann sel...@endpoint.com writes:
Currently, load_hba() bails on the first parsing error. It would be
better for the typo-prone sysadmin if it reported ALL errors, and THEN
bailed out.
This patch implements that behavior. Tested against 8.4 HEAD this morning.
It sure looks
Tom Lane wrote:
Selena Deckelmann sel...@endpoint.com writes:
Currently, load_hba() bails on the first parsing error. It would be
better for the typo-prone sysadmin if it reported ALL errors, and THEN
bailed out.
This patch implements that behavior. Tested against 8.4 HEAD this morning.
Magnus Hagander mag...@hagander.net writes:
Tom Lane wrote:
It sure looks like that's going to try to free new_parsed_lines more
than once. Shouldn't clean_hba_list be done just once?
Yeah, it should be done in the if branch down below. And I think by our
coding standards (or at least by
Hi,
Le 7 mars 09 à 02:44, Josh Berkus a écrit :
Thing is, anybody can institute their own naming convention. I've
long used v_ as a prefix. Allowing : would save me some keystrokes,
but that's about it.
What I usually do in those cases is abusing the ALIAS option of
DECLARE (because as
In fact, maybe a new option to set the OUT parameters prefix to use
from within the function body would do?
Le 7 mars 09 à 19:56, Dimitri Fontaine a écrit :
CREATE OR REPLACE FUNCTION test_out
(
IN a integer,
IN b integer,
OUT s integer
)
RETURNS setof integer
SET out_prefix TO 'v_'
Tom Lane wrote:
alvhe...@postgresql.org (Alvaro Herrera) writes:
Avoid MSVC breakage caused by my previous commit by not using a variable in
the src/bin/scripts Makefile.
Buildfarm says it's still broken.
Hmm, yeah, apparently Mkvcbuild.pm needs to be updated with the list of
files that
Tom Lane wrote:
Magnus Hagander mag...@hagander.net writes:
Tom Lane wrote:
It sure looks like that's going to try to free new_parsed_lines more
than once. Shouldn't clean_hba_list be done just once?
Yeah, it should be done in the if branch down below. And I think by our
coding standards
Dimitri Fontaine dfonta...@hi-media.com writes:
I'd sure be happy not having to do it explicitly, but schema-style
prefixing has the drawback of needing to avoid any user defined
schema.
No, not really, because it'd be the wrong number of naming levels.
Assuming that we were to switch to
On Sat, Mar 7, 2009 at 11:32 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sat, Mar 7, 2009 at 9:08 AM, Rod Taylor rod.tay...@gmail.com wrote:
It wouldn't be so bad if you could assign internal and external column
names.
This is a good point. Uglifying
Robert Haas robertmh...@gmail.com writes:
I think that would definitely be an improvement. Would that mean that
in a query like the following:
SELECT t.id FROM test t WHERE t.id = 17
...it wouldn't consider replacing t? That all by itself would be an
improvement...
It's already the case
Hiroshi Saito wrote:
Hi.
Ummm, I present is not understood by the reason of Japanese. ...
Therefore, It was made into the Spanish case. I know that Alvaro-san will
understand Spanish well.
==postgresql.conf==
lc_messages= 'es'
server.log of a patch before and after was applied.
Alvaro Herrera alvhe...@commandprompt.com writes:
Understood. In fact, after having a look at this patch and giving it a
little refactoring I think it's pretty obvious; right now we're calling
bind_textdomain_codeset only for the main domain, and with this patch we
also set it for all other
Tom Lane wrote:
o...@pyrenet.fr writes:
the only thing I could come with is a calloc(1,12) that seems to alloc
mem for filename, in that case sdewitte.dmp; so the alloc is not counting
the null char at the end.
Where do you see that? The memtool dump you sent doesn't show it
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Understood. In fact, after having a look at this patch and giving it a
little refactoring I think it's pretty obvious; right now we're calling
bind_textdomain_codeset only for the main domain, and with this patch we
also
Hi all,
I'm sending this to -hackers because i don't now if it is a bug or a
expected behavior.
I have the view bellow (if the selects bellow shows unformated in this
email, i put this in http://guedesoft.net/txt/vw_error.txt too. ):
CREATE OR REPLACE VIEW vw_my_test AS
SELECT
DISTINCT
Dickson S. Guedes lis...@guedesoft.net writes:
And bellow is the select that returns: ERROR: failed to locate grouping
columns
when no rows is returned by the View above, but it runs well when one or more
rows is returned by same view.
I really have a hard time believing that whether you get
Em Sáb, 2009-03-07 às 19:38 -0500, Tom Lane escreveu:
Dickson S. Guedes lis...@guedesoft.net writes:
And bellow is the select that returns: ERROR: failed to locate grouping
columns
when no rows is returned by the View above, but it runs well when one or
more
rows is returned by same
On Sat, Mar 7, 2009 at 5:08 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I think that would definitely be an improvement. Would that mean that
in a query like the following:
SELECT t.id FROM test t WHERE t.id = 17
...it wouldn't consider replacing t?
Hi Alvaro-san.
Yeah, It seems that it saves also except pl. then, It also regards me as very
good.
I tested just now, of course, it is very comfortable. :-)
== try ==
C:\workpsql -e -f plpgsql_test.sql
show client_encoding;
client_encoding
-
latin1
(1 row)
show
Here's an attempt on my part to summarize the status of the remaining patches.
* SE-PostgreSQL. Generally positive feedback from Heikki. New
version expected Monday 3/9, with changes to walker.c as requested by
Heikki. Rest of patch reviewable in the meantime.
Robert Haas robertmh...@gmail.com writes:
[ much snipped ]
* GIN fast insert. Tom Lane committed some planner changes that make
it possible for an AM to not support index scans, and posted the
remaining patch. No one other than me has spoken in favor of retaing
support for index scans, so
On Sat, Mar 7, 2009 at 9:35 PM, Tom Lane t...@sss.pgh.pa.us wrote:
* Proposal of PITR performance improvement. Fujii Masao posted an
updated version of this patch. I believe it has yet to be reviewed by
a committer.
Has it been reviewed by anybody? There's no trace of reviewing work
on the
On Sat, Mar 7, 2009 at 9:35 PM, Tom Lane t...@sss.pgh.pa.us wrote:
* GIN fast insert. Tom Lane committed some planner changes that make
it possible for an AM to not support index scans, and posted the
remaining patch. No one other than me has spoken in favor of retaing
support for index
2009/3/7 Dimitri Fontaine dfonta...@hi-media.com:
In fact, maybe a new option to set the OUT parameters prefix to use from
within the function body would do?
Le 7 mars 09 à 19:56, Dimitri Fontaine a écrit :
CREATE OR REPLACE FUNCTION test_out
(
IN a integer,
IN b integer,
OUT s
39 matches
Mail list logo
