Re: [HACKERS] Out parameters handling
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 >> ) >> RETURNS setof integer > > SET out_prefix TO 'v_' -1 this is out of PL languages. There is not well enough solved access to table out variables. Actually these variables are same as out variables, but internally we should distinct between. For example: PL/pgPSM don't declare it as variables - so there isn't possible any conflict. fragment of plpgpsm code create or replace function test_out(a int, b int) returns table (s int) as $$ return table(select s from some) $$ language plpgpsm is correct. regards Pavel Stehule >> LANGUAGE PLPGSQL >> AS $f$ > > Those two following lines would be deprecated: > >> DECLARE >> v_s ALIAS FOR $3; > > >> BEGIN >> FOR v_s IN SELECT generate_series(a, b) >> LOOP >> v_s := v_s * v_s; >> RETURN NEXT; >> END LOOP; >> RETURN; >> END; >> $f$; >> >> CREATE FUNCTION >> dim=# SELECT * FROM test_out(2, 4); >> s >> >> 4 >> 9 >> 16 >> (3 rows) > > -- > dim > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] status of remaining patches
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 Teodor should just apply the rest of >> this (perhaps with the minor wordsmithing I suggested in the second >> message linked below, or something similar). Or if not, then we >> should decide that this will wait for 8.5 - it's time to fish or cut >> bait. > > My feeling about it is that the insert speed improvement is worth > the loss of simple indexscan support. Perhaps in 8.5 or later we can > think of some reasonable approach that will let simple indexscans be > put back into GIN, but there's not time left for that for 8.4. > > I'm not sure the patch is actually ready to commit --- the documentation > certainly needs more work, and I've not read any of the code except for > the planner bits. But I think it's probably close, if we can get past > this basic question of what the scope of the patch is. How do we get past that question? >> * Improve Performance of Multi-Batch Hash Join for Skewed Data Sets. >> Tom Lane reviewed this patch, and Ramon Lawrence responded, but it's >> not clear to me where we go from here. > > I don't think this one is that far away either. I've been holding Bryce > and Ramon's feet to the fire on the issue of possible downside, but so > far there's not really much evidence of any *actual* as opposed to > theoretical downside. What bothers me more after having looked at the > patch is that it's got the executor taking decisions that rightfully > belong in the planner (mainly because the planner should know whether > IM will be used in order to assign a correct cost estimate). That > probably won't take much work to fix though, it's just moving some code > and creating more path/plan node fields to carry the results. So are you going to do that and commit it, or do you want them to rework it further? ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] status of remaining patches
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 commitfest page. Personally I've been ignoring it on the > assumption that someone else should review it first. Yes. The original patch was submitted by Koichi Suzuki - quite a few other people have looked at it and provided comments. Simon Riggs was assigned as the original reviewer, but for some reason Dave Page removed his name from the wiki a few days ago (I'm fixing this now). Actually, this patch has been reviewed by a whole slough of people. V1: http://archives.postgresql.org/message-id/87fxmhc7sc@oxford.xeocode.com (Greg Stark) http://archives.postgresql.org/message-id/490703b6.9060...@enterprisedb.com (Heikki Linnakangas - I forgot about this when I made my previous statement that it hadn't been looked at by a committer yet; this was a while ago) http://archives.postgresql.org/message-id/1225269154.3971.278.ca...@ebony.2ndquadrant (Simon Riggs) V2: http://archives.postgresql.org/message-id/1228145754.20796.311.ca...@hp_dx2400_1 (Simon Riggs) http://archives.postgresql.org/message-id/3f0b79eb0812022255v45cbbfaau292f5320620ed...@mail.gmail.com (Fujii Masao) V3: http://archives.postgresql.org/message-id/87hc4qrw5e@oxford.xeocode.com (quick comment from Greg Stark, no formal review) V4: http://archives.postgresql.org/message-id/20090114101659.89cd.52131...@oss.ntt.co.jp (Itagaki Takahiro) http://archives.postgresql.org/message-id/8763k3lgyy@oxford.xeocode.com (Greg Stark) As far as I can tell the patch author has responded to all comments and pretty much done everything right. I haven't even looked at it enough to understand what it does or why I should care, but AFAICS it's had more interest and more reviewing than 90% of what was submitted for this CommitFest. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] status of remaining patches
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 should just apply the rest of > this (perhaps with the minor wordsmithing I suggested in the second > message linked below, or something similar). Or if not, then we > should decide that this will wait for 8.5 - it's time to fish or cut > bait. My feeling about it is that the insert speed improvement is worth the loss of simple indexscan support. Perhaps in 8.5 or later we can think of some reasonable approach that will let simple indexscans be put back into GIN, but there's not time left for that for 8.4. I'm not sure the patch is actually ready to commit --- the documentation certainly needs more work, and I've not read any of the code except for the planner bits. But I think it's probably close, if we can get past this basic question of what the scope of the patch is. > * Improve Performance of Multi-Batch Hash Join for Skewed Data Sets. > Tom Lane reviewed this patch, and Ramon Lawrence responded, but it's > not clear to me where we go from here. I don't think this one is that far away either. I've been holding Bryce and Ramon's feet to the fire on the issue of possible downside, but so far there's not really much evidence of any *actual* as opposed to theoretical downside. What bothers me more after having looked at the patch is that it's got the executor taking decisions that rightfully belong in the planner (mainly because the planner should know whether IM will be used in order to assign a correct cost estimate). That probably won't take much work to fix though, it's just moving some code and creating more path/plan node fields to carry the results. > * 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 commitfest page. Personally I've been ignoring it on the assumption that someone else should review it first. > * Reducing some DDL Locks to ShareLock. A substantial part of this > was committed, and there hasn't been a new version of this patch in > three months, so I think it should be bounced at this point. But I > don't want to do that myself unless someone at least makes some kind > of noise of agreement. Can I get a +1, or two? Certainly Simon has been given more than enough time to do something about this patch. It should probably go to "returned with feedback" until a new version does surface. (IIRC, the part that got committed was just some minor catalog infrastructure tweaking, it wasn't substantial in terms of addressing the real goals of the patch.) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] status of remaining patches
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/pgsql-hackers/2009-03/msg00192.php * 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 should just apply the rest of this (perhaps with the minor wordsmithing I suggested in the second message linked below, or something similar). Or if not, then we should decide that this will wait for 8.5 - it's time to fish or cut bait. http://archives.postgresql.org/pgsql-hackers/2009-03/msg00220.php http://archives.postgresql.org/pgsql-hackers/2009-03/msg00224.php * B-Tree emulation for GIN. Teodor posted a new version of this patch and is awaiting a response to a few questions he had. http://archives.postgresql.org/pgsql-hackers/2009-03/msg00198.php * Improve Performance of Multi-Batch Hash Join for Skewed Data Sets. Tom Lane reviewed this patch, and Ramon Lawrence responded, but it's not clear to me where we go from here. http://archives.postgresql.org/pgsql-hackers/2009-03/msg00273.php * 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. http://archives.postgresql.org/pgsql-hackers/2009-03/msg00064.php * Reducing some DDL Locks to ShareLock. A substantial part of this was committed, and there hasn't been a new version of this patch in three months, so I think it should be bounced at this point. But I don't want to do that myself unless someone at least makes some kind of noise of agreement. Can I get a +1, or two? ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: Redefine _() to dgettext()instead of gettext() so that it uses
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_encoding; server_encoding - UTF8 (1 row) set lc_messages to es; SET show lc_messages; lc_messages - es (1 row) create function func1() returns int as ' begin select "a; end; ' language 'plpgsql'; psql:plpgsql_test.sql:10: ERROR: un identificador entre comillas está inconcluso CONTEXT: compilation of PL/pgSQL function "func1" near line 2 ==/END Thanks! Regards, Hiroshi Saito - Original Message - From: "Alvaro Herrera" 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 other domains we use. More generally, should we push the bindtextdomain calls themselves into the new function (and perhaps call it something else than SetDomainCodeSet)? Seems like logically this should be thought of as all one operation, ie, it's not clear to me that it ever makes sense to call bindtextdomain without also worrying about encoding. I'm not sure that can be made to work easily. On the backend itself we call bindtextdomain in set_pglocale_pgservice() which is also used by programs in src/bin/. Shuffling things in there would be more involved than seems worth. As for names, how about pg_bind_textdomain_codeset? -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Out parameters handling
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 an >> improvement... > > It's already the case that plpgsql knows enough to not replace "t" > in the context "t.something". But I suppose you are talking about the > alias declaration. Yeah, that should get better if we push this into > the main parser. +1 from me then. >> I actually feel like the best thing to do would be to error out if >> there's an ambiguous reference. If you write this: >> SELECT id FROM foo, bar WHERE foo.a = bar.a >> ...it will complain if both foo.id and bar.id are defined. So if I write: >> SELECT id FROM foo >> ...shouldn't it complain if both foo.id and .id >> are defined? > > No, on the principle that more closely nested definitions take > precedence. The reason the first example merits an error is that the > two possible sources of the name have equal precedence. That's reasonable, but I'm not a huge fan. The fact that host and guest variables live in the same namespace is a huge source of bugs. Your idea above is an improvement IMO but I wish there were some way to make it airtight. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ERROR: "failed to locate grouping columns"
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. > > I really have a hard time believing that whether you get that error is > contingent on whether the view returns some rows or not. That's a > planner message and couldn't possibly have to do with what happens > at runtime. And I was really confused when I've tested. I've seen that it's a planner message, then I discard SUBSELECTs and use JOINs and it works. > Would you put together a complete example, instead of leaving us to > guess what's underlying the view? Ok, I'll prepare a full test and send it. > And what PG version is this? Oh! I forgot to say, the version is 8.3.6. Thanks. -- Dickson S. Guedes - mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://planeta.postgresql.org.br -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ERROR: "failed to locate grouping columns"
"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 is contingent on whether the view returns some rows or not. That's a planner message and couldn't possibly have to do with what happens at runtime. Would you put together a complete example, instead of leaving us to guess what's underlying the view? And what PG version is this? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] ERROR: "failed to locate grouping columns"
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 cv.cv_cdct AS cdct, -- returns a int4 cv.cv_cdcp AS cdcp, -- returns a numeric ( SELECT cp.cp_nmfts FROM cptv cp WHERE cp.cp_cdcp = cv.cv_cdcp) AS nmfts, -- returns a varchar epr.epr_nrctn AS nrctn,-- returns a numeric cv.cv_tpvnc AS tpvnc, -- returns a int4 ( SELECT rg.rg_dsc FROM rgst rg WHERE rg.rg_idrg = cv.cv_tpvnc) AS dsc_vnc, -- returns a varchar cv.cv_ndcdv AS ndcdv_prnc, -- returns a varchar ( SELECT ps.ps_nm FROM pss ps WHERE ps.ps_nrdc = cv.cv_ndcdv) AS nmdvprnc, -- returns a varchar cvd.cvd_nmdvsld AS ndcdv_sld, -- returns a varchar ( SELECT ps.ps_nm FROM pss ps WHERE ps.ps_nrdc = cvd.cvd_nmdvsld) AS nmdvsld, -- returns a varchar cv.cv_vltt AS vltt,-- returns a numeric(18,2) ( SELECT max(oc.oc_dtagn) AS max FROM ocr oc WHERE oc.oc_cdct = ev.ev_cdct) AS dtagn, -- returns a date ( SELECT CASE WHEN abs(min(pe.pe_dtvnc) - date(now())) <= 15 THEN 1231230 WHEN abs(min(pe.pe_dtvnc) - date(now())) >= 16 AND abs(min(pe.pe_dtvnc) - date(now())) <= 30 THEN 1341231 WHEN abs(min(pe.pe_dtvnc) - date(now())) >= 31 AND abs(min(pe.pe_dtvnc) - date(now())) <= 45 THEN 2345342 WHEN abs(min(pe.pe_dtvnc) - date(now())) >= 46 AND abs(min(pe.pe_dtvnc) - date(now())) <= 60 THEN 654653 WHEN abs(min(pe.pe_dtvnc) - date(now())) >= 61 AND abs(min(pe.pe_dtvnc) - date(now())) <= 90 THEN 45254 WHEN abs(min(pe.pe_dtvnc) - date(now())) >= 91 AND abs(min(pe.pe_dtvnc) - date(now())) <= 180 THEN 13425 WHEN abs(min(pe.pe_dtvnc) - date(now())) >= 181 AND abs(min(pe.pe_dtvnc) - date(now())) <= 360 THEN 12346 ELSE 13417 END AS "case" FROM pcep pe WHERE pe.pe_nrcntr = ev.ev_nrcntr) AS dsatr, cv.cv_stc AS stc, rg.rg_cdrgs AS cdrgs, rg.rg_dsc AS dsc_stc FROM epvnc ev JOIN ctvn cv ON cv.cv_cdct = ev.ev_cdct JOIN eptm epr ON epr.epr_nrcntr = ev.ev_nrcntr JOIN rgst rg ON cv.cv_stc = rg.rg_idrg LEFT JOIN cvdvsld cvd ON cvd.cvd_cdct = cv.cv_cdct ; 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. --- SELECT cdcp, nmfts, nrctn, tpvnc, dsc_vnc, ndcdv_prnc, nmdvpr, ndcdv_sld, max(vltt) FROM vw_my_test_ GROUP BY cdcp, nmfts, nrctn, tpvnc, dsc_vnc, ndcdv_prnc, nmdvpr, ndcdv_sld; --- If i group only by the *int* or *numeric* fields the error don't occurs, it only shows if i use a varchar in group by and the view returns 0 records If i change the view above to use JOINs then all works fine... meaning the problem is something in SUBSELECTs and VARCHAR used in that way. Is this a bug or a expected behavior? best regards. -- Dickson S. Guedes - mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://planeta.postgresql.org.br -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: Redefine _() to dgettext() instead of gettext() so that it uses
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 other domains we use.
> More generally, should we push the bindtextdomain calls themselves into
> the new function (and perhaps call it something else than
> SetDomainCodeSet)? Seems like logically this should be thought of as
> all one operation, ie, it's not clear to me that it ever makes sense to
> call bindtextdomain without also worrying about encoding.
I'm not sure that can be made to work easily. On the backend itself we
call bindtextdomain in set_pglocale_pgservice() which is also used by
programs in src/bin/. Shuffling things in there would be more involved
than seems worth.
As for names, how about pg_bind_textdomain_codeset?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
Index: src/backend/utils/init/miscinit.c
===
RCS file: /home/alvherre/Code/cvs/pgsql/src/backend/utils/init/miscinit.c,v
retrieving revision 1.172
diff -c -p -r1.172 miscinit.c
*** src/backend/utils/init/miscinit.c 5 Jan 2009 13:57:12 - 1.172
--- src/backend/utils/init/miscinit.c 7 Mar 2009 23:39:00 -
***
*** 30,35
--- 30,36
#endif
#include "catalog/pg_authid.h"
+ #include "mb/pg_wchar.h"
#include "miscadmin.h"
#include "postmaster/autovacuum.h"
#include "storage/fd.h"
*** pg_bindtextdomain(const char *domain)
*** 1241,1246
--- 1242,1248
get_locale_path(my_exec_path, locale_path);
bindtextdomain(domain, locale_path);
+ pg_bind_textdomain_codeset(domain, GetDatabaseEncoding());
}
#endif
}
Index: src/backend/utils/mb/mbutils.c
===
RCS file: /home/alvherre/Code/cvs/pgsql/src/backend/utils/mb/mbutils.c,v
retrieving revision 1.79
diff -c -p -r1.79 mbutils.c
*** src/backend/utils/mb/mbutils.c 2 Mar 2009 15:10:09 - 1.79
--- src/backend/utils/mb/mbutils.c 7 Mar 2009 23:37:22 -
*** SetDatabaseEncoding(int encoding)
*** 891,912
DatabaseEncoding = &pg_enc2name_tbl[encoding];
Assert(DatabaseEncoding->encoding == encoding);
! /*
! * On Windows, we need to explicitly bind gettext to the correct
! * encoding, because gettext() tends to get confused.
! */
#if defined(ENABLE_NLS) && defined(WIN32)
! {
! int i;
! for (i = 0; i < sizeof(codeset_map_array) / sizeof(codeset_map_array[0]); i++)
{
! if (codeset_map_array[i].encoding == encoding)
! {
! if (bind_textdomain_codeset(textdomain(NULL), codeset_map_array[i].codeset) == NULL)
! elog(LOG, "bind_textdomain_codeset failed");
! break;
! }
}
}
#endif
--- 891,917
DatabaseEncoding = &pg_enc2name_tbl[encoding];
Assert(DatabaseEncoding->encoding == encoding);
! pg_bind_textdomain_codeset(textdomain(NULL), encoding);
! }
!
! /*
! * On Windows, we need to explicitly bind gettext to the correct
! * encoding, because gettext() tends to get confused.
! */
! void
! pg_bind_textdomain_codeset(const char *domainname, int encoding)
! {
#if defined(ENABLE_NLS) && defined(WIN32)
! int i;
! for (i = 0; i < lengthof(codeset_map_array); i++)
! {
! if (codeset_map_array[i].encoding == encoding)
{
! if (bind_textdomain_codeset(domainname,
! codeset_map_array[i].codeset) == NULL)
! elog(LOG, "bind_textdomain_codeset failed");
! break;
}
}
#endif
Index: src/include/mb/pg_wchar.h
===
RCS file: /home/alvherre/Code/cvs/pgsql/src/include/mb/pg_wchar.h,v
retrieving revision 1.84
diff -c -p -r1.84 pg_wchar.h
*** src/include/mb/pg_wchar.h 10 Feb 2009 19:29:39 - 1.84
--- src/include/mb/pg_wchar.h 7 Mar 2009 23:37:42 -
*** extern const char *pg_get_client_encodin
*** 392,397
--- 392,398
extern void SetDatabaseEncoding(int encoding);
extern int GetDatabaseEncoding(void);
extern const char *GetDatabaseEncodingName(void);
+ extern void pg_bind_textdomain_codeset(const char *domainname, int encoding);
extern int pg_valid_client_encoding(const char *name);
extern int pg_valid_server_encoding(const char *name);
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] small parallel restore optimization
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 AFAICS. And the only copying of the filename that I can find is done with strdup(). cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: Redefine _() to dgettext() instead of gettext() so that it uses
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 this patch work for you? Seems like this comment needs to move into the new function: >* On Windows, we need to explicitly bind gettext to the correct >* encoding, because gettext() tends to get confused. More generally, should we push the bindtextdomain calls themselves into the new function (and perhaps call it something else than SetDomainCodeSet)? Seems like logically this should be thought of as all one operation, ie, it's not clear to me that it ever makes sense to call bindtextdomain without also worrying about encoding. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: Redefine _() to dgettext() instead of gettext() so that it uses
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. Please see it.
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 this patch work for you?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
Index: src/backend/utils/init/miscinit.c
===
RCS file: /home/alvherre/Code/cvs/pgsql/src/backend/utils/init/miscinit.c,v
retrieving revision 1.172
diff -c -p -r1.172 miscinit.c
*** src/backend/utils/init/miscinit.c 5 Jan 2009 13:57:12 - 1.172
--- src/backend/utils/init/miscinit.c 7 Mar 2009 22:13:47 -
*** pg_bindtextdomain(const char *domain)
*** 1241,1246
--- 1241,1248
get_locale_path(my_exec_path, locale_path);
bindtextdomain(domain, locale_path);
+
+ SetDomainCodeSet(domain, GetDatabaseEncoding());
}
#endif
}
Index: src/backend/utils/mb/mbutils.c
===
RCS file: /home/alvherre/Code/cvs/pgsql/src/backend/utils/mb/mbutils.c,v
retrieving revision 1.79
diff -c -p -r1.79 mbutils.c
*** src/backend/utils/mb/mbutils.c 2 Mar 2009 15:10:09 - 1.79
--- src/backend/utils/mb/mbutils.c 7 Mar 2009 22:13:47 -
*** SetDatabaseEncoding(int encoding)
*** 895,912
* On Windows, we need to explicitly bind gettext to the correct
* encoding, because gettext() tends to get confused.
*/
#if defined(ENABLE_NLS) && defined(WIN32)
! {
! int i;
! for (i = 0; i < sizeof(codeset_map_array) / sizeof(codeset_map_array[0]); i++)
{
! if (codeset_map_array[i].encoding == encoding)
! {
! if (bind_textdomain_codeset(textdomain(NULL), codeset_map_array[i].codeset) == NULL)
! elog(LOG, "bind_textdomain_codeset failed");
! break;
! }
}
}
#endif
--- 895,916
* On Windows, we need to explicitly bind gettext to the correct
* encoding, because gettext() tends to get confused.
*/
+ SetDomainCodeSet(textdomain(NULL), encoding);
+ }
+
+ void
+ SetDomainCodeSet(const char *domainname, int encoding)
+ {
#if defined(ENABLE_NLS) && defined(WIN32)
! int i;
! for (i = 0; i < sizeof(codeset_map_array) / sizeof(codeset_map_array[0]); i++)
! {
! if (codeset_map_array[i].encoding == encoding)
{
! if (bind_textdomain_codeset(domainname, codeset_map_array[i].codeset) == NULL)
! elog(LOG, "bind_textdomain_codeset failed");
! break;
}
}
#endif
Index: src/include/mb/pg_wchar.h
===
RCS file: /home/alvherre/Code/cvs/pgsql/src/include/mb/pg_wchar.h,v
retrieving revision 1.84
diff -c -p -r1.84 pg_wchar.h
*** src/include/mb/pg_wchar.h 10 Feb 2009 19:29:39 - 1.84
--- src/include/mb/pg_wchar.h 7 Mar 2009 22:21:51 -
*** extern const char *pg_get_client_encodin
*** 392,397
--- 392,398
extern void SetDatabaseEncoding(int encoding);
extern int GetDatabaseEncoding(void);
extern const char *GetDatabaseEncodingName(void);
+ extern void SetDomainCodeSet(const char *domainname, int encoding);
extern int pg_valid_client_encoding(const char *name);
extern int pg_valid_server_encoding(const char *name);
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Out parameters handling
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 knows enough to not replace "t" in the context "t.something". But I suppose you are talking about the alias declaration. Yeah, that should get better if we push this into the main parser. > I actually feel like the best thing to do would be to error out if > there's an ambiguous reference. If you write this: > SELECT id FROM foo, bar WHERE foo.a = bar.a > ...it will complain if both foo.id and bar.id are defined. So if I write: > SELECT id FROM foo > ...shouldn't it complain if both foo.id and .id > are defined? No, on the principle that more closely nested definitions take precedence. The reason the first example merits an error is that the two possible sources of the name have equal precedence. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Out parameters handling
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 parameters, but is much more annoying for output parameters. > > How much of this pain would go away if we changed over to the arguably > correct (as in Or*cle does it that way) scoping for names, wherein the > parser first tries to match a name against column names of tables of the > current SQL statement, and only failing that looks to see if they are > plpgsql variables? 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... I actually feel like the best thing to do would be to error out if there's an ambiguous reference. If you write this: SELECT id FROM foo, bar WHERE foo.a = bar.a ...it will complain if both foo.id and bar.id are defined. So if I write: SELECT id FROM foo ...shouldn't it complain if both foo.id and .id are defined? ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Out parameters handling
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 rules, we would have: x in the context of a table name = table x x.y in the context of a table name = table y, schema x x in the context of an expression = first of column x from some table of the current command most-closely-nested plpgsql variable x x.y in the context of an expression = first of column y from table x of the current command plpgsql variable y in block x The important point here is that the main SQL parser can tell whether it's looking at a table name or a column name, whereas plpgsql is currently too stupid for that and will always substitute for a name that matches a plpgsql variable name. Once we get rid of that problem there isn't really any conflict with schema names. You might have a conflict between table aliases and block names, but that can be dealt with by local renaming of aliases within the problematic command. (Note: as pointed out by Pavel, it's already the case that named parameters are implicitly assigned a block name equal to the function name; so you can qualify them if you have to.) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_hba.conf - patch to report all parsing errors, and then bail
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 least by our conventions), the variable should >> be "ok" and not "OK". > >> Unless there are any objections, I can do those cleanups and apply it. > > I thought the adjacent comments could do with a bit more wordsmithing, > also, but otherwise that about covers it. Applied. //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Re: [COMMITTERS] pgsql: Avoid MSVC breakage caused by my previous commit by not using a
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 need to be symlinked -- and it's not all that straightforward. I need some help here, as I have no way to test this. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Out parameters handling
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_' LANGUAGE PLPGSQL AS $f$ Those two following lines would be deprecated: DECLARE v_s ALIAS FOR $3; BEGIN FOR v_s IN SELECT generate_series(a, b) LOOP v_s := v_s * v_s; RETURN NEXT; END LOOP; RETURN; END; $f$; CREATE FUNCTION dim=# SELECT * FROM test_out(2, 4); s 4 9 16 (3 rows) -- dim -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Out parameters handling
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 mentioned somewhere else in this thread, you generally don't want to have that ugly OUT parameters, you want a nice API) : CREATE OR REPLACE FUNCTION test_out ( IN a integer, IN b integer, OUT s integer ) RETURNS setof integer LANGUAGE PLPGSQL AS $f$ DECLARE v_s ALIAS FOR $3; BEGIN FOR v_s IN SELECT generate_series(a, b) LOOP v_s := v_s * v_s; RETURN NEXT; END LOOP; RETURN; END; $f$; CREATE FUNCTION dim=# SELECT * FROM test_out(2, 4); s 4 9 16 (3 rows) 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. Maybe pg_plout would do? Regards, -- dim -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_hba.conf - patch to report all parsing errors, and then bail
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), the variable should > be "ok" and not "OK". > Unless there are any objections, I can do those cleanups and apply it. I thought the adjacent comments could do with a bit more wordsmithing, also, but otherwise that about covers it. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_hba.conf - patch to report all parsing errors, and then bail
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 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), the variable should be "ok" and not "OK". Unless there are any objections, I can do those cleanups and apply it. //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_hba.conf - patch to report all parsing errors, and then bail
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 to try to free new_parsed_lines more than once. Shouldn't clean_hba_list be done just once? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] pg_hba.conf - patch to report all parsing errors, and then bail
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 more
complicated and will be a separate patch.
-selena
--
Selena Deckelmann
End Point Corporation
sel...@endpoint.com
503-282-2512
diff --git a/src/backend/libpq/hba.c b/src/backend/libpq/hba.c
index 6923d06..c6a7ba7 100644
--- a/src/backend/libpq/hba.c
+++ b/src/backend/libpq/hba.c
@@ -1304,6 +1304,7 @@ load_hba(void)
List *hba_line_nums = NIL;
ListCell *line, *line_num;
List *new_parsed_lines = NIL;
+ bool OK = true;
file = AllocateFile(HbaFileName, "r");
if (file == NULL)
@@ -1332,17 +1333,22 @@ load_hba(void)
if (!parse_hba_line(lfirst(line), lfirst_int(line_num),
newline))
{
- /* Parse error in the file, so bail out */
+ /* Parse error in the file, so indicate there's a
problem */
free_hba_record(newline);
pfree(newline);
clean_hba_list(new_parsed_lines);
/* Error has already been reported in the parsing
function */
- return false;
+ OK = false;
+ continue;
}
new_parsed_lines = lappend(new_parsed_lines, newline);
}
+ if (!OK)
+ /* Parsing failed, so bail out */
+ return false;
+
/* Loaded new file successfully, replace the one we use */
clean_hba_list(parsed_hba_lines);
parsed_hba_lines = new_parsed_lines;
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Out parameters handling
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 not be solved. One typical beginer's bug has similar symptoms. create function foo(tablename varchar, param varchar, paramname varchar) returns .. begin select into .. .. from tablename where .paramname = param This is bug - who can understand, if this is desired behave or nonsense. you have to use dynamic SQL. All what are inside literal, are independent. postgres=# create table wrong(a integer); CREATE TABLE postgres=# insert into wrong values(10); INSERT 0 1 postgres=# create function fx3(out wrong varchar) returns setof varchar as $$ begin for wrong in execute 'select * from wrong' loop return next; end loop; return; end; $$ language plpgsql; CREATE FUNCTION postgres=# select * from fx3(); ┌───┐ │ wrong │ ├───┤ │ 10│ └───┘ (1 row) regards Pavel Stehule Actually dynamic sql are little bit uncomfortable. It's much better in 8.4. regards Pavel Stehule > Really don't want to prefix all tables with a hardcoded schema or do > variable substitution for loading the document. > > Not fond of prefixing with function name either as a) many of my > functions have very long names and b) they change names occasionally, > particularly during development. > > A short prefix like "out" would be useful. I would immediately start > prefixing all uses. > > rbt=# begin; > BEGIN > rbt=# create table b (col integer); > CREATE TABLE > rbt=# insert into b values (2); > INSERT 0 1 > rbt=# create or replace function fx2(a integer, out b integer) as $$ > rbt$# begin > rbt$# SELECT col > rbt$# INTO fx2.b > rbt$# FROM b; > rbt$# > rbt$# return; > rbt$# end; $$ language plpgsql; > ERROR: syntax error at or near "$1" > LINE 1: SELECT col FROM $1 > ^ > QUERY: SELECT col FROM $1 > CONTEXT: SQL statement in PL/PgSQL function "fx2" near line 4 > rbt=# > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Out parameters handling
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 parameters, but is much more annoying for output parameters. > > How much of this pain would go away if we changed over to the arguably > correct (as in Or*cle does it that way) scoping for names, wherein the > parser first tries to match a name against column names of tables of the > current SQL statement, and only failing that looks to see if they are > plpgsql variables? This would solve all of my conflicts correctly. I nearly always use RETURN QUERY with OUT parameters. An alternative would be the requirement to prefix out parameters with "out", "export", or something similar, so the plain non-prefixed name is never replaced. "b" in the below is the table. I hit this quite a bit since my historical table name might be "foo_bar_baz" which is the same as the most relevant name for the out parameter. I've debated renaming all of my tables t_* on more than one occasion as a workaround in applications which exclusively use functions to access/write data. create or replace function read_some_data_from_data_region(a integer, out b integer) as $$ begin SELECT col INTO out.b FROM b; return; end; $$ language plpgsql; -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Out parameters handling
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 >> variable but only in contexts where an expression is valid. > > AFAICS getting that "right" would require the parser to develop advanced > mind reading capabilities. We could probably fix it to know that the > first "balance" must be a table column name, but there is no principled > way to make a choice about the second one; and you could easily invent > slightly different scenarios where resolving it as the column name is > the right thing. > > Anyway, I'm unsure whether this is related to the complaints upthread, > which is why I was asking. > > regards, tom lane I thing, we mainly need detection of this situation. It is same as detection of ambiguous column names in SQL. PL/pgSQL has enough tools for solving - main problem is in detection. After detection of some possible conflict we should to raise exception or warning (controlled by GUC). regards Pavel Stehule > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Out parameters handling
> 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 for loading the document. Not fond of prefixing with function name either as a) many of my functions have very long names and b) they change names occasionally, particularly during development. A short prefix like "out" would be useful. I would immediately start prefixing all uses. rbt=# begin; BEGIN rbt=# create table b (col integer); CREATE TABLE rbt=# insert into b values (2); INSERT 0 1 rbt=# create or replace function fx2(a integer, out b integer) as $$ rbt$# begin rbt$# SELECT col rbt$# INTO fx2.b rbt$# FROM b; rbt$# rbt$# return; rbt$# end; $$ language plpgsql; ERROR: syntax error at or near "$1" LINE 1: SELECT col FROM $1 ^ QUERY: SELECT col FROM $1 CONTEXT: SQL statement in PL/PgSQL function "fx2" near line 4 rbt=# -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Out parameters handling
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 where an expression is valid. AFAICS getting that "right" would require the parser to develop advanced mind reading capabilities. We could probably fix it to know that the first "balance" must be a table column name, but there is no principled way to make a choice about the second one; and you could easily invent slightly different scenarios where resolving it as the column name is the right thing. Anyway, I'm unsure whether this is related to the complaints upthread, which is why I was asking. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Out parameters handling
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 annoying for output parameters. > > How much of this pain would go away if we changed over to the arguably > correct (as in Or*cle does it that way) scoping for names, wherein the > parser first tries to match a name against column names of tables of the > current SQL statement, and only failing that looks to see if they are > plpgsql variables? 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 where an expression is valid. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Out parameters handling
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 AS "foo" >> >> >> Another alternative is requiring a prefix like plout for the >> replacement to occur: >> >> ( OUT foo varchar ) >> >> BEGIN >> SELECT foo.somename INTO plout.foo FROM foo WHERE id = 10; >> >> RETURN NEXT; >> >> RETURN; >> END; > > This is a good point. Uglifying the parameter names is sort of OK for > input parameters, but is much more annoying for output parameters. > > ...Robert > hello actually - function name should be used as label now. This code is working: postgres=# create or replace function fx2(a integer, out b integer, out c integer) as $$ begin fx2.b := a + 10; fx2.c := a + 30; return; end; $$ language plpgsql; CREATE FUNCTION postgres=# select * from fx2(20); ┌┬┐ │ b │ c │ ├┼┤ │ 30 │ 50 │ └┴┘ (1 row) regards Pavel Stehule -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] small parallel restore optimization
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. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Out parameters handling
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. How much of this pain would go away if we changed over to the arguably correct (as in Or*cle does it that way) scoping for names, wherein the parser first tries to match a name against column names of tables of the current SQL statement, and only failing that looks to see if they are plpgsql variables? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Out parameters handling
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 alternative is requiring a prefix like plout for the > replacement to occur: > > ( OUT foo varchar ) > > BEGIN > SELECT foo.somename INTO plout.foo FROM foo WHERE id = 10; > > RETURN NEXT; > > RETURN; > END; This is a good point. Uglifying the parameter names is sort of OK for input parameters, but is much more annoying for output parameters. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] field with single quote no longer works in 8.3.5
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 dutch-field containing single quotes unfindable. You could argue that it's a bad practice to include records with single quotes in a field but in language related applications it's unavoidable as single quotes are used and escaping every single quote when adding data to the database is something you can't ask the user. example of a dutch field which causes the problem: hij zei: 'het is waar' I guess there must be a way to escape the single quotes automatically without rebuilding the database any help appreciated hugo -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Out parameters handling
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: ( OUT foo varchar ) BEGIN SELECT foo.somename INTO plout.foo FROM foo WHERE id = 10; RETURN NEXT; RETURN; END; On Sat, Mar 7, 2009 at 8:50 AM, Robert Haas wrote: > 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 who are > annoyed by the current behavior. Maybe we should all just learn to > live with it. > > ...Robert > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Out parameters handling
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 who are annoyed by the current behavior. Maybe we should all just learn to live with it. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: Redefine _() to dgettext() instead of gettext() so that it uses
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, Hiroshi Saito - Original Message - From: "Hiroshi Saito" Hi Peter-san. I see the problem for being an original domain in plpgsql. It differs from what codeset meant at postmaster by Japanese windows Please see, this look at the problem on which SJIS enters into a message. http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/plpgsql/before_plpgsql_server.log This state is the following. == lc_messages=ja server_encoding=utf-8 == Therefore, it needs to be codeset called for an original domain. It is the procedure in which only a server module must correspond. Then, It is solvable by this patch. http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/plpgsql/after_plpgsql_server.log Please take this into consideration. Tahnks. Regards, Hiroshi Saito - Original Message - From: "Peter Eisentraut" Alvaro Herrera wrote: Peter Eisentraut wrote: Log Message: --- Redefine _() to dgettext() instead of gettext() so that it uses the plpgsql text domain, instead of the postgres one (or whatever the default may be). Hmm, so is this needed on all other PLs too? In principle yes. Or call dgettext() explicitly, which is also done in some cases. However, in most cases messages are issued through ereport(), which handles this automatically (which you implemented, I recall). plpgsql_es_before.log Description: Binary data plpgsql_es_after.log Description: Binary data plpgsql_test.sql 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
