2009/3/7 Dimitri Fontaine :
> 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
>>
On Sat, Mar 7, 2009 at 9:35 PM, Tom Lane 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 scans, so maybe
On Sat, Mar 7, 2009 at 9:35 PM, Tom Lane 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 commitfes
Robert Haas 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 maybe Teodor shou
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.
http://archives.postgresql.org/pg
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:\work>psql -e -f plpgsql_test.sql
show client_encoding;
client_encoding
-
latin1
(1 row)
show server_encodin
On Sat, Mar 7, 2009 at 5:08 PM, Tom Lane wrote:
> Robert Haas 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 a
Em Sáb, 2009-03-07 às 19:38 -0500, Tom Lane escreveu:
> "Dickson S. Guedes" 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.
>
"Dickson S. Guedes" 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 that error i
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
Tom Lane wrote:
> Alvaro Herrera 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 othe
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 AFAI
Alvaro Herrera 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 domains we use.
> Does
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 appl
Robert Haas 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 that plpgsql kn
On Sat, Mar 7, 2009 at 11:32 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Sat, Mar 7, 2009 at 9:08 AM, Rod Taylor 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
Dimitri Fontaine 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 Oracle-style naming
Tom Lane wrote:
> Magnus Hagander 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
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
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_'
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
Magnus Hagander 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 our conventions
Tom Lane wrote:
> Selena Deckelmann 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 su
Selena Deckelmann 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 like that's going t
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 little
Hello
2009/3/7 Rod Taylor :
>> 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 so this should
On Sat, Mar 7, 2009 at 11:32 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Sat, Mar 7, 2009 at 9:08 AM, Rod Taylor 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
Hello
2009/3/7 Tom Lane :
> Gregory Stark 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
>
> 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 fo
Gregory Stark 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 only in contexts whe
Tom Lane writes:
> Robert Haas writes:
>> On Sat, Mar 7, 2009 at 9:08 AM, Rod Taylor 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 more an
2009/3/7 Robert Haas :
> On Sat, Mar 7, 2009 at 9:08 AM, Rod Taylor 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
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.
Robert Haas writes:
> On Sat, Mar 7, 2009 at 9:08 AM, Rod Taylor 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 more annoying for output parameters.
On Sat, Mar 7, 2009 at 9:08 AM, Rod Taylor 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 alterna
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
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 occu
On Fri, Mar 6, 2009 at 8:44 PM, Josh Berkus 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 of people
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,
Hiro
39 matches
Mail list logo
