Re: [HACKERS] PG 7.3 is five years old today
Hi, On Tue, 2007-11-27 at 14:26 -0500, Tom Lane wrote: > > I assume you no longer need to maintain it for Redhat then? > > Well, I still do, nominally, but RHEL-3 is in maintenance mode > (meaning no more scheduled updates). It would take a fairly serious > bug to get Red Hat's attention to the point that they'd want to turn > the package. So +1 for dropping support for 7.3, per these. BTW, we can provide community RPMs for 7.3+RHEL 3, if needed... /me will be very happy to drop 7.3 packages from his list. Regards, -- Devrim GÜNDÜZ , RHCE PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/ signature.asc Description: This is a digitally signed message part
Re: [HACKERS] Time to update list of contributors
IMHO, it may not be a bad idea to list countries , it shows the diversity of the community. -Original Message- From: "Gregory Stark" <[EMAIL PROTECTED]> To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> Cc: "pgsql-hackers@postgresql.org" ; "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> Sent: 28/11/2007 06:30 Subject: Re: [HACKERS] Time to update list of contributors "Josh Berkus" <[EMAIL PROTECTED]> writes: > All, > > Time for the annual update of this list: >... > Greg Stark, USA I'm not sure what the countries are supposed to signify but that's neither the country I hail from nor where I'm currently living. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's PostGIS support! ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [pgsql-www] Time to update list of contributors
Josh Berkus wrote: > All, > > Time for the annual update of this list: > http://www.postgresql.org/developer/bios > > Here's the list of people I gleaned from the release notes (btw, if people > have countries for the folks who aren't attributed, I'd appreciate them). > Of course, there are many contributors to essential non-core code who > should be listed as well: Hiroshi Saito has made a number of smaller but important contributions this cycle. Heikki is from Finland, but currently living in the UK. You also missed my name despite it being attributed to 3 items in the release notes, but I don't suppose that matters as I'm in the core section anyway. /D ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Time to update list of contributors
On Tue, Nov 27, 2007 at 04:08:36PM -0800, Josh Berkus wrote: > All, > > Time for the annual update of this list: > http://www.postgresql.org/developer/bios > > Here's the list of people I gleaned from the release notes (btw, if people > have countries for the folks who aren't attributed, I'd appreciate them). > Of course, there are many contributors to essential non-core code who > should be listed as well: The mentioned page has a split in "core", "major" and "other" developers. The first part is easy, but a difference is needed between the other two I think. As for those we don't have info for, we could always email them and ask? For major developers, we also list company name if they're working on company time... > Magnus Haeglander, Sweden Cool new spelling. Maybe I should start using that one :-) Did you just come up with it, or is that actually in some document somewhere? //Magnus ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Quality and Performance
On Tue, 27 Nov 2007, Simon Riggs wrote: My vision for that is a set of tests that test very specific aspects of code, much the same way as the regression tests attempt feature coverage. Examples would be - 1 INSERTs - 1 INSERTs using multi-VALUEs clauses - 10 rows inserted by COPY - 10 rows inserted by CTAS In addition to these, there's actually a nice set of sample primitive operations to test included in the "Advanced transactional" section of sysbench: http://sysbench.sourceforge.net/docs/#database_mode I have code that does this sort of thing, including tests at multiple client loads, that even spits out HTML for the results. It's based on pgbench and I sent out hundreds of results generated by it when I was doing the background writer optimization. The results are thoroughly boring on just my system, and I'm just waiting for a larger server to be available before it's worth my trouble to revive that project. Once such a system becomes available, I could have a basic set of tests like these ready the day after I get a login. That's not to say what you're talking about isn't needed, because using pgbench introduces some limitations and buildfarm integration is a whole different topic. But I have made a first move here and only need the hardware to become available before I can produce something useful with it. -- * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] [pgsql-www] Time to update list of contributors
Dave Page wrote: Josh Berkus wrote: All, Time for the annual update of this list: http://www.postgresql.org/developer/bios Here's the list of people I gleaned from the release notes (btw, if people have countries for the folks who aren't attributed, I'd appreciate them). Of course, there are many contributors to essential non-core code who should be listed as well: Hiroshi Saito has made a number of smaller but important contributions this cycle. Heikki is from Finland, but currently living in the UK. You also missed my name despite it being attributed to 3 items in the release notes, but I don't suppose that matters as I'm in the core section anyway. yeah well - the release notes do not make that good a reference on the "who submitted patches" question anyway because the do not contain stuff that are mere compile failures or add support for additional platforms/cleanups) of new features (ie my patches to add GSSAPI support to OpenBSD/Solaris or things full text command/tabcomplete support in psql). So in effect that list might more correctly be called a "feature contributor list" Stefan ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] String encoding during connection "handshake"
Ok, that's bad. I've also read crypt.c and md5.c. And what a nightmare is C compared to Java (granted, there's a difference in age of more than 20 years). My guess is that since the "char" type is one byte long, all "char *" expressions are actually pointers to array of bytes which are transmitted through the wire and/or stored in the database. When these strings arrive from or leave for a client that has another declared encoding than the database, the string of bytes is replaced with an equivalent one from a Unicode perspective. Am I right? During the authentication phase, no such conversion takes place - you were right and I couldn't believe it! In the case when your database name, your user name or password contain non-ASCII characters, you're out of luck if the stored values were submitted in another encoding by the administrator. I assume that no names conversion takes place between client and cluster metadata when a role is created (CREATE ROLE... PASSWORD...) or when a database is created (CREATE DATABASE...). Or does it? In that case, the names are encoded in the encoding of the database that the administrator was connected to. Thank you both. On Tuesday 27 November 2007, Usama Munir wrote: > Martin is actually right. No assumption is made about the encoding of the > password. The password is recieved as a set of bytes over the wire-level > protocol and then processed accordingly as per your pg_hba settings. please > refer to auth.c method recv_password_packet(Port *port). The comment on the > last line of the method might be of your intrest, and i quote > > "Return the received string, Note we do not attempt to do any character set > conversion on it; since we don't know the client's encoding, there woudn't > be much point" > > / Usama ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] [pgsql-www] Time to update list of contributors
Stefan Kaltenbrunner wrote: > yeah well - the release notes do not make that good a reference on the > "who submitted patches" question anyway because the do not contain stuff > that are mere compile failures or add support for additional > platforms/cleanups) of new features (ie my patches to add GSSAPI support > to OpenBSD/Solaris or things full text command/tabcomplete support in > psql). > So in effect that list might more correctly be called a "feature > contributor list" Agreed - and that's exactly why Hiroshi got left off I think. His work included lots of testing and subsequent platform specific build fixes and code cleanup/fixes. I should also point out that the contributor list has always included people who have contributed to non-core community projects in the past as well - psqlODBC, the JDBC driver, pgInstaller, pgAccess, pgAdmin, infrastructure/web etc. so Josh's update should not necessarily remove those people (though an argument could be made for giving those people their own section). /D ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] SQL:2008
I ask you to implement ideas, stated in http://sql2008.euro.ru/sql2008.ppt (description is in http://sql2008.euro.ru/zip/sql2008-allfiles.zip) in MySql. I'm ready to aswer to any your questions. Dmitry Turin ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] SQL:2008 (some correction)
I ask you to implement ideas, stated in http://sql2008.euro.ru/sql2008.ppt (description is in http://sql2008.euro.ru/zip/sql2008-allfiles.zip) in Postgres. I'm ready to aswer to any your questions. Dmitry Turin ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] pgindent and multiline string constants
Somehow pgindent appears to do odd things with multiline string constants, such as somefunc(&blah, "lots of text" "with mulitple lines" "like this"); Afterwards this looks more like this: somefunc(&blah, "lots of text" "with mulitple lines" "like this"); As an example, compare these two files: http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/adt/xml.c?rev=1.56;content-type=text%2Fplain http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/adt/xml.c?rev=1.57;content-type=text%2Fplain function map_sql_type_to_xmlschema_type() somewhere near the end of the file; look at the appendStringInfo(&result, ...) calls. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Still a NOTICE in dict_thesaurus.c
Bruce Momjian wrote: > I have applied the attached patch to change the NOTICE to ERROR. Thanks > for spotting this. FYI, at this time only the German and French translations have been updated almost fully, and none of them is yet 100% in the backend translation. I think it's appropriate to mark this string for translation at this time (i.e. turn it into an ereport call). -- Alvaro Herrera http://www.amazon.com/gp/registry/DXLWNGRJD34J "Hay quien adquiere la mala costumbre de ser infeliz" (M. A. Evans) ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] unclear enum error messages
There are a few error messages like this in the code:
/*
* We rely on being able to get the specific enum type from the calling
* expression tree. The generic type mechanism should have ensured that
* both are of the same type.
*/
enumtypoid = get_fn_expr_argtype(fcinfo->flinfo, 0);
if (enumtypoid == InvalidOid)
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("could not determine actual enum
type")));
First, isn't this an internal error?
What is an actual enum type? And how should a user react if he got this
message? I would ask, "why not?".
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
Re: [HACKERS] PG 7.3 is five years old today
Tom Lane napsal(a): Comments, opinions? Is it time to remove old communication protocol support and cleanup code in 8.4? Zdenek ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] PG 7.3 is five years old today
I'm not a developper, but it occured to me that you should consider dropping the support for client-server wire protocol v2. I quote a comment I found in JDBC driver's code: // NOTE: To simplify this code, it is assumed that if we are // using the V3 protocol, then the database is at least 7.4. That // eliminates the need to check database versions and maintain // backward-compatible code here. // // Change by Chris Smith <[EMAIL PROTECTED]> This tells me that the v3 protocol appeared at 7.4, so there's no need to support v2 in future database versions (starting with 8.3?). It would simplify code in interfaces like JDBC too. > > I see that there are two or three minor bug fixes in the REL7_3_STABLE > > branch since 7.3.20. Rather than just leaving those to rot, maybe the > > actual policy should be "only one more update after 8.3 comes out". > > > > Comments, opinions? > > Release 7.3.21 with and EOL addendum :). E.g; this is the last release > of 7.3 and 7.3 is now considered unsupported. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] PG 7.3 is five years old today
I'm not a developper, but it occured to me that you should consider dropping the support for client-server wire protocol v2. I quote a comment I found in JDBC driver's code: // NOTE: To simplify this code, it is assumed that if we are // using the V3 protocol, then the database is at least 7.4. That // eliminates the need to check database versions and maintain // backward-compatible code here. // // Change by Chris Smith <[EMAIL PROTECTED]> This tells me that the v3 protocol appeared at 7.4, so there's no need to support v2 in future database versions (starting with 8.3?). It would simplify code in interfaces like JDBC too. > > I see that there are two or three minor bug fixes in the REL7_3_STABLE > > branch since 7.3.20. Rather than just leaving those to rot, maybe the > > actual policy should be "only one more update after 8.3 comes out". > > > > Comments, opinions? > > Release 7.3.21 with and EOL addendum :). E.g; this is the last release > of 7.3 and 7.3 is now considered unsupported. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] PG 7.3 is five years old today
Alexandru Cârstoiu <[EMAIL PROTECTED]> writes: > This tells me that the v3 protocol appeared at 7.4, so there's no need to > support v2 in future database versions (starting with 8.3?). It would > simplify code in interfaces like JDBC too. I think the second half of this is correct. There would be no need to support the old protocol in client interface drivers since the only supported databases would all support the new protocol. Whether there's any need to support the old protocol in the server depends on whether there are any clients out there which use it which is harder to determine and not affected by whether Postgres 7.3 is still around. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's On-Demand Production Tuning ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Time to update list of contributors
"Gregory Stark" <[EMAIL PROTECTED]> writes: > "Josh Berkus" <[EMAIL PROTECTED]> writes: > >> All, >> >> Time for the annual update of this list: >>... >> Greg Stark, USA > > I'm not sure what the countries are supposed to signify but that's neither the > country I hail from nor where I'm currently living. Sorry, forgot to say what to put instead. I'll go with "Canada" -- it's more exotic :) -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training! ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [GENERAL] Empty arrays with ARRAY[]
Brendan Jurd escribió: > If the only reason for keeping A_Const->typename around is the alleged > code saving (as indicated by the code comments), my offer to do away > with it is still on the table. Code cleanup is always welcome. -- Alvaro Herrera Developer, http://www.PostgreSQL.org/ "The eagle never lost so much time, as when he submitted to learn of the crow." (William Blake) ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] pgwin32_open returning EINVAL
Hi,
We've seen several cases of people (running 8.1 or 8.2) that see
messages like this:
2007-11-26 11:41:59 ERROR: could not open relation 1663/352369/353685: Invalid
argument
The platform is Win32.
The problem is that pgwin32_open reduces any error code from
GetLastError that's not ERROR_PATH_NOT_FOUND, ERROR_FILE_NOT_FOUND,
ERROR_FILE_EXISTS or ERROR_ACCESS_DENIED into EINVAL, without further
notice. This is problematic because the true cause of the problem is
being hidden and it's hard to track down what's going on.
Can we do something like this to report the Win32 error code so that the
user has a higher chance of figuring out what's going on?
--
Alvaro Herrera Developer, http://www.PostgreSQL.org/
"Las navajas y los monos deben estar siempre distantes" (Germán Poo)
Index: src/port/open.c
===
RCS file: /home/alvherre/Code/cvs/pgsql/src/port/open.c,v
retrieving revision 1.21
diff -c -p -r1.21 open.c
*** src/port/open.c 15 Nov 2007 21:14:46 - 1.21
--- src/port/open.c 28 Nov 2007 14:56:04 -
*** pgwin32_open(const char *fileName, int f
*** 88,94
((fileFlags & O_DSYNC) ? FILE_FLAG_WRITE_THROUGH : 0),
NULL)) == INVALID_HANDLE_VALUE)
{
! switch (GetLastError())
{
/* EMFILE, ENFILE should not occur from CreateFile. */
case ERROR_PATH_NOT_FOUND:
--- 88,96
((fileFlags & O_DSYNC) ? FILE_FLAG_WRITE_THROUGH : 0),
NULL)) == INVALID_HANDLE_VALUE)
{
! DWORD err = GetLastError();
!
! switch (err)
{
/* EMFILE, ENFILE should not occur from CreateFile. */
case ERROR_PATH_NOT_FOUND:
*** pgwin32_open(const char *fileName, int f
*** 102,107
--- 104,111
errno = EACCES;
break;
default:
+ ereport(LOG,
+ (errmsg("win32 error code: %d", err)));
errno = EINVAL;
}
return -1;
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
Re: [HACKERS] Still a NOTICE in dict_thesaurus.c
Alvaro Herrera <[EMAIL PROTECTED]> writes: > FYI, at this time only the German and French translations have been > updated almost fully, and none of them is yet 100% in the backend > translation. I think it's appropriate to mark this string for > translation at this time (i.e. turn it into an ereport call). Yeah, I saw a number of elogs that should be ereports in the tsearch code during some idle looking yesterday. I'm planning to go through it a bit more systematically today and fix what needs fixing. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] PG 7.3 is five years old today
On Wednesday 28 November 2007, Gregory Stark wrote: > > This tells me that the v3 protocol appeared at 7.4, so there's no need to > > support v2 in future database versions (starting with 8.3?). It would > > simplify code in interfaces like JDBC too. > > I think the second half of this is correct. There would be no need to > support the old protocol in client interface drivers since the only > supported databases would all support the new protocol. > > Whether there's any need to support the old protocol in the server depends > on whether there are any clients out there which use it which is harder to > determine and not affected by whether Postgres 7.3 is still around. Actually it doesn't make sense to do it halfway (for example, why would you keep the v2 protocol in the database if it is not supported anymore by clients?!). Either you drop v2 support or you don't, if the community is keen on preserving compatibility between "any" client and "any" database. I for one am not keen on that. Just as I would drop support for Java older than 1.4 in the JDBC driver. Anyway, the decision is not mine. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] pgwin32_open returning EINVAL
On Wed, Nov 28, 2007 at 11:57:35AM -0300, Alvaro Herrera wrote: > Can we do something like this to report the Win32 error code so that the > user has a higher chance of figuring out what's going on? The Windows API provides a way to get the error message associated with the code. It seems it would be more user-friendly if the message was displayed (just as for unix) rather than the code. Have a nice day, -- Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/ > Those who make peaceful revolution impossible will make violent revolution > inevitable. > -- John F Kennedy signature.asc Description: Digital signature
Re: [HACKERS] String encoding during connection "handshake"
On Wed, Nov 28, 2007 at 11:39:33AM +0200, [EMAIL PROTECTED] wrote: > During the authentication phase, no such conversion takes place - you were > right and I couldn't believe it! In the case when your database name, your > user name or password contain non-ASCII characters, you're out of luck if the > stored values were submitted in another encoding by the administrator. The problem is, what conversion. You don't know the encoding of the server yet (because you havn't selected a DB) and you don't know the encoding to the client. The only real possibility is to declare One True Encoding and decree every username/password be in that. But you're never going to get people to agree on that. > I assume that no names conversion takes place between client and cluster > metadata when a role is created (CREATE ROLE... PASSWORD...) or when a > database is created (CREATE DATABASE...). Or does it? In that case, the names > are encoded in the encoding of the database that the administrator was > connected to. Honestly, UNIX usernames/passwords have always worked like this so we're not really doing anything wierd by doing it this way. Users need to type the password in the same encoding it was added. It not usually a big deal because people set their own passwords... Have a nice day, -- Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/ > Those who make peaceful revolution impossible will make violent revolution > inevitable. > -- John F Kennedy signature.asc Description: Digital signature
Re: [HACKERS] pgwin32_open returning EINVAL
Martijn van Oosterhout wrote: > On Wed, Nov 28, 2007 at 11:57:35AM -0300, Alvaro Herrera wrote: > > Can we do something like this to report the Win32 error code so that the > > user has a higher chance of figuring out what's going on? > > The Windows API provides a way to get the error message associated > with the code. It seems it would be more user-friendly if the message > was displayed (just as for unix) rather than the code. Yeah, I looked into that (it's FormatMessage) but it's sufficiently hard to use that I refrained. All the more when I can't actually compile that code. -- Alvaro Herrerahttp://www.advogato.org/person/alvherre "Nunca se desea ardientemente lo que solo se desea por razón" (F. Alexandre) ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Sorting Improvements for 8.4
On Tue, Nov 27, 2007 at 06:03:46PM +, Simon Riggs wrote: > Just wanted to review a few thoughts and ideas around improving external > sorts, as recently encouraged to do by Jim Nasby. Is there any way of PG knowing that having an index on a subset of the sorted columns is sometimes a win? For example, if we have: CREATE TABLE foo ( a INTEGER NOT NULL PRIMARY KEY, b INTEGER NOT NULL, c INTEGER ); and we request: SELECT * FROM foo ORDER BY a,b LIMIT 10; then it may be a win to do smaller sorts for each value of "a", rather than one big sort after all the data has been pulled out. Obviously, it would depend on the distribution of "a", large numbers of distinct values for "a" being good, and a small number being bad. I think this would help in a number of other situations as well, but that's just the most obvious case. Sam ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] PG 7.3 is five years old today
Gregory Stark <[EMAIL PROTECTED]> writes: > Whether there's any need to support the old protocol in the server depends on > whether there are any clients out there which use it which is harder to > determine and not affected by whether Postgres 7.3 is still around. Right. There's really not much to be gained by dropping it on the server side anyway. libpq might possibly be simplified by a useful amount, but on the other hand we probably want to keep its current structure for the inevitable v4 protocol. Another area where we might think about dropping some stuff is pg_dump. If we got rid of the requirement to support dumps from pre-7.3 servers then it could assume server-side dependencies exist, and lose all the code for trying to behave sanely without 'em. regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] PG 8.3beta3 Segmentation Fault during Database Restore
It looks like a corrupted-data kind of problem. Can you extract a reproducible test case? The problem was the hardware!! On a second system (Mac Power G5) there was no failure, i.e. the error is not reproducible. Thanks for your help. Rudolf VanderLeeden ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] unclear enum error messages
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> There are a few error messages like this in the code:
> /*
> * We rely on being able to get the specific enum type from the
> calling
> * expression tree. The generic type mechanism should have ensured
> that
> * both are of the same type.
> */
> enumtypoid = get_fn_expr_argtype(fcinfo->flinfo, 0);
> if (enumtypoid == InvalidOid)
> ereport(ERROR,
> (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
> errmsg("could not determine actual enum
> type")));
> First, isn't this an internal error?
Not necessarily; there are many code paths by which a function could get
called without argument-type info. Thus the FEATURE_NOT_SUPPORTED
classification.
> What is an actual enum type? And how should a user react if he got this
> message? I would ask, "why not?".
Yeah, I would too, but without a concrete example to look at it's hard
to say if the situation could be improved.
regards, tom lane
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [HACKERS] 8.3beta3 ERROR: cached plan must not change result type
On Wed, Nov 28, 2007 at 10:45:31AM -0500, Tom Lane wrote: > Louis-David Mitterrand <[EMAIL PROTECTED]> writes: > > I am seeing this error with 8.3beta3 on debian unstable: > > > 2007-11-28 15:15:46 CET ERROR: cached plan must not change result type > > > Let me know if you need more info. > > Yes. Okay :) I guess I had it coming. The only thing I know is this error started showing up in the logs at 15:15:46 making our site unavailble until I restarted apache. No postgres code has been modified recently on the app and it's the first time I see that error. Also I don't know, yet, how to reproduce it. Will try and report. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] 8.3beta3 ERROR: cached plan must not change result type
Louis-David Mitterrand <[EMAIL PROTECTED]> writes: > I am seeing this error with 8.3beta3 on debian unstable: > 2007-11-28 15:15:46 CET ERROR: cached plan must not change result type > Let me know if you need more info. Yes. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[HACKERS] 8.3beta3 ERROR: cached plan must not change result type
Hi, I am seeing this error with 8.3beta3 on debian unstable: 2007-11-28 15:15:46 CET ERROR: cached plan must not change result type 2007-11-28 15:15:46 CET STATEMENT: SELECT s.*, coalesce(d.firstname||' ','')||coalesce(d.lastname,'') as person_name, person_url(d.id_person), t.person_type, t.id_person from show s left join person_to_show t using (id_show) left join person d using (id_person) where s.id_show = $1 The query is sent by a mod_perl app and a restart of apache2 fixes it. Let me know if you need more info. Cheers, ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] String encoding during connection "handshake"
Martijn, :) don't take it personal, I am just trying to obtain confirmation that I understood well the problem. Afterall, it's just that C has a very outdated notion of "char"s (and no notion of Unicode). I was naively under the impression that "char"s have evolved in nowadays C. Regarding the problem of "One True Encoding", the answer seems obvious to me: use only one encoding per database cluster, either UTF-8 or UTF-16 or another Unicode-aware scheme, whichever yields a statistically smaller database for the languages employed by the users in their data. This encoding should be a one time choice! De facto, this is already happening now, because one cannot change collation rules after a cluster has been created. During the handshake, all clients should be assumed to serve data in the cluster's encoding. Have a nice day, too. On Wednesday 28 November 2007, Martijn van Oosterhout wrote: > On Wed, Nov 28, 2007 at 11:39:33AM +0200, [EMAIL PROTECTED] wrote: > > During the authentication phase, no such conversion takes place - you > > were right and I couldn't believe it! In the case when your database > > name, your user name or password contain non-ASCII characters, you're out > > of luck if the stored values were submitted in another encoding by the > > administrator. > > The problem is, what conversion. You don't know the encoding of the > server yet (because you havn't selected a DB) and you don't know the > encoding to the client. The only real possibility is to declare One > True Encoding and decree every username/password be in that. But you're > never going to get people to agree on that. > > > I assume that no names conversion takes place between client and cluster > > metadata when a role is created (CREATE ROLE... PASSWORD...) or when a > > database is created (CREATE DATABASE...). Or does it? In that case, the > > names are encoded in the encoding of the database that the administrator > > was connected to. > > Honestly, UNIX usernames/passwords have always worked like this so > we're not really doing anything wierd by doing it this way. Users need > to type the password in the same encoding it was added. It not usually > a big deal because people set their own passwords... > > Have a nice day, ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] String encoding during connection "handshake"
[EMAIL PROTECTED] escribió: > Martijn, > > :) don't take it personal, I am just trying to obtain confirmation that I > understood well the problem. Afterall, it's just that C has a very outdated > notion of "char"s (and no notion of Unicode). I was naively under the > impression that "char"s have evolved in nowadays C. This is not the language's fault in any way. We support plenty of encodings beyond UTF-8. -- Alvaro Herrera http://www.amazon.com/gp/registry/5ZYLFMCVHXC "La grandeza es una experiencia transitoria. Nunca es consistente. Depende en gran parte de la imaginación humana creadora de mitos" (Irulan) ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [pgsql-www] Time to update list of contributors
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 28 Nov 2007 09:46:36 + Dave Page <[EMAIL PROTECTED]> wrote: > I should also point out that the contributor list has always included > people who have contributed to non-core community projects in the past > as well - psqlODBC, the JDBC driver, pgInstaller, pgAccess, pgAdmin, > infrastructure/web etc. so Josh's update should not necessarily > remove those people (though an argument could be made for giving > those people their own section). This list seems to be oddly designed anyway. Who is a developer? Is a developer different than a -hacker? Not to mention there don't seem to be any defined rules. I asked Berkus and his reply was, "It has always been a little fuzzy". I asked Devrim and he gave me 5 bullet points that don't quite make sense. Further I think this list is in the wrong place. It is under /developers which to mean is most intuitive to information "for" developers not a listing of them. I think the listing should probably go under about/contributors and under contributors would be: Core <-- this is obvious Committers <-- this is obvious the only question is it only committers to the source tree or do we want to give equal billing to the -www guys (I think yes to equal billing) Members (really I think this should be contributors but then it is duplicative) Hacker Emeritus Special Thanks (not sure about this, but basically this is "others") Sincerely, Joshua D. Drake - -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240 PostgreSQL solutions since 1997 http://www.commandprompt.com/ UNIQUE NOT NULL Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHTZU3ATb/zqfZUUQRAoHMAJ4gwAkOshe9+PbusrcaECb2HgGr2wCeOzQX nY1eWHCq+NdV6F3DXvO3QXI= =4Jri -END PGP SIGNATURE- ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] pgwin32_open returning EINVAL
On Wed, Nov 28, 2007 at 12:24:26PM -0300, Alvaro Herrera wrote: > Martijn van Oosterhout wrote: > > On Wed, Nov 28, 2007 at 11:57:35AM -0300, Alvaro Herrera wrote: > > > Can we do something like this to report the Win32 error code so that the > > > user has a higher chance of figuring out what's going on? We already do something very similar to what you're donig in backend/port/wni32/socket.c :: TranslateSocketError(). So I think it's a good idea to do it, yes. > > The Windows API provides a way to get the error message associated > > with the code. It seems it would be more user-friendly if the message > > was displayed (just as for unix) rather than the code. > > Yeah, I looked into that (it's FormatMessage) but it's sufficiently hard > to use that I refrained. All the more when I can't actually compile > that code. It's fairly trivial to use, really. See for example pg_SSPI_error in auth.c. But if it only happens rarely, we shouldn't need it. Let's try it with just an int for now, and we can perhaps detect the specific cases when it happens often, and deal with those separately. I can put together one that uses messages if you want me to (since I can compile it...) though. I assume you consider your current patch safe enough not to need help buiklding that part before it hits the buildfarm :-P //Magnus ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] PG 7.3 is five years old today
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 28 Nov 2007 13:30:55 + Gregory Stark <[EMAIL PROTECTED]> wrote: > Alexandru Cârstoiu <[EMAIL PROTECTED]> writes: > > > This tells me that the v3 protocol appeared at 7.4, so there's no > > need to support v2 in future database versions (starting with > > 8.3?). It would simplify code in interfaces like JDBC too. > > I think the second half of this is correct. There would be no need to > support the old protocol in client interface drivers since the only > supported databases would all support the new protocol. Except that we just broke the proposed upgrade path if we do that... Let's not put people in a catch-22. Joshua D. Drake - -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240 PostgreSQL solutions since 1997 http://www.commandprompt.com/ UNIQUE NOT NULL Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHTZWlATb/zqfZUUQRAr81AJ0SnmMp8cbPk99ELPqtSeGC6hgK7gCeMypg tE0pv8Gq8N3wlFOD4NOgFL8= =Mlaj -END PGP SIGNATURE- ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [pgsql-www] Time to update list of contributors
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 28 Nov 2007 13:58:27 + Gregory Stark <[EMAIL PROTECTED]> wrote: > "Gregory Stark" <[EMAIL PROTECTED]> writes: > > > "Josh Berkus" <[EMAIL PROTECTED]> writes: > > > >> All, > >> > >> Time for the annual update of this list: > >>... > >> Greg Stark, USA > > > > I'm not sure what the countries are supposed to signify but that's > > neither the country I hail from nor where I'm currently living. > > Sorry, forgot to say what to put instead. I'll go with "Canada" -- > it's more exotic :) I believe the list is where you are actually at. Aren't you in the UK right now? Joshua D. Drake - -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240 PostgreSQL solutions since 1997 http://www.commandprompt.com/ UNIQUE NOT NULL Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHTZXYATb/zqfZUUQRAmHiAKCtbqqBKQTMuA8jn0J/Kl+B357dLwCgp312 awpJs8KeGYnWVM+mQXyAVls= =/Lqi -END PGP SIGNATURE- ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [pgsql-www] Time to update list of contributors
Joshua D. Drake wrote: > Not to mention there don't seem to be any defined rules. I asked Berkus > and his reply was, "It has always been a little fuzzy". I asked Devrim > and he gave me 5 bullet points that don't quite make sense. Not sure what Devrim is referring to, but most often in the past Rob (or someone else) has proposed changes to -core which we've said yay or nay to. > Further I think this list is in the wrong place. It is > under /developers which to mean is most intuitive to information "for" > developers not a listing of them. Maybe. Where else would it go? > I think the listing should probably go under about/contributors and > under contributors would be: > >Core <-- this is obvious >Committers <-- this is obvious the only question is it only > committers to the source tree or do we want to give equal billing to > the -www guys (I think yes to equal billing) Actually we've previously agreed (in -core) that we do not want to list committers for various reasons. Yeah, I know the list isn't too hard to figure out, but we don't want to advertise it. >Members (really I think this should be contributors but then it is > duplicative) Why not Hackers? Noone is a 'member' of anything except core or mayber the web/infrastructure team. /D ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] jaguar is up
Jaguar is a new animal meant to test specific defines as asked by Tom sometime ago. Right now, it compiles and runs with -DCLOBBER_CACHE_ALWAYS Let me know if you want me to add/change flags Best regards -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [pgsql-www] Time to update list of contributors
"Joshua D. Drake" <[EMAIL PROTECTED]> writes: > On Wed, 28 Nov 2007 13:58:27 + > Gregory Stark <[EMAIL PROTECTED]> wrote: > >> "Gregory Stark" <[EMAIL PROTECTED]> writes: >> >> > "Josh Berkus" <[EMAIL PROTECTED]> writes: >> > >> >> All, >> >> >> >> Time for the annual update of this list: >> >>... >> >> Greg Stark, USA >> > >> > I'm not sure what the countries are supposed to signify but that's >> > neither the country I hail from nor where I'm currently living. >> >> Sorry, forgot to say what to put instead. I'll go with "Canada" -- >> it's more exotic :) > > I believe the list is where you are actually at. Aren't you in the UK > right now? Yep. That's fine with me too. Perhaps it's even better if there's any thought of using this list to drive the advocacy or user group efforts. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services! ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [pgsql-www] Time to update list of contributors
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 28 Nov 2007 16:27:42 + Dave Page <[EMAIL PROTECTED]> wrote: > Actually we've previously agreed (in -core) that we do not want to > list committers for various reasons. Yeah, I know the list isn't too > hard to figure out, but we don't want to advertise it. Oh right, I actually recall that... > > >Members (really I think this should be contributors but then it > > is duplicative) > > Why not Hackers? Noone is a 'member' of anything except core or mayber > the web/infrastructure team. Define Hacker. And I could argue that some are members of PGDG. What about those who provide just as much time and energy in advocacy as others do on -heackers? What about people that are working on external projects only such as Slony or PLproxy? Sincerely, Joshua D. Drake - -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240 PostgreSQL solutions since 1997 http://www.commandprompt.com/ UNIQUE NOT NULL Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHTZgrATb/zqfZUUQRAnS1AKCc/Nv3HmC+oX47GwBrXK9ChfoTaQCgitNG sGbIf6/G87bgwSiGEVCcacQ= =3StH -END PGP SIGNATURE- ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] String encoding during connection "handshake"
On Wed, Nov 28, 2007 at 05:54:05PM +0200, [EMAIL PROTECTED] wrote: > Regarding the problem of "One True Encoding", the answer seems obvious to me: > use only one encoding per database cluster, either UTF-8 or UTF-16 or another > Unicode-aware scheme, whichever yields a statistically smaller database for > the languages employed by the users in their data. This encoding should be a > one time choice! De facto, this is already happening now, because one cannot > change collation rules after a cluster has been created. Umm, each database in a cluster can have a different encoding, so there is no such thing as the "cluster's encoding". You can certainly argue that it should be a one time choice, but I doubt you'll get people to remove the possibilites we have now. If fact, if anything we'd probably go the otherway, allow you to select the collation on a per database/table/column level (SQL complaince requires this). This has nothing to do with C by the way. C has many features that allow you to work with different encodings. It just doesn't force you to use any particular one. Have a nice day, -- Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/ > Those who make peaceful revolution impossible will make violent revolution > inevitable. > -- John F Kennedy signature.asc Description: Digital signature
Re: [HACKERS] [pgsql-www] Time to update list of contributors
Joshua D. Drake wrote: > On Wed, 28 Nov 2007 16:27:42 + > Dave Page <[EMAIL PROTECTED]> wrote: > >> Why not Hackers? Noone is a 'member' of anything except core or mayber >> the web/infrastructure team. > > Define Hacker. And I could argue that some are members of PGDG. Says he who only the other day muttered something about how PGDG wasn't a defined entity :-) > What > about those who provide just as much time and energy in advocacy as > others do on -heackers? What about people that are working on external > projects only such as Slony or PLproxy? The latter are still hackers using the definition we're likely to agree on (ie. not a cracker). Both groups are 'Contributors' though. Maybe just use 'Regular contributors' and 'Occasional contributors'. Or major and minor. Or something entirely different. /D ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [pgsql-www] Time to update list of contributors
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 28 Nov 2007 16:53:43 + Dave Page <[EMAIL PROTECTED]> wrote: > Joshua D. Drake wrote: > > On Wed, 28 Nov 2007 16:27:42 + > > Dave Page <[EMAIL PROTECTED]> wrote: > > > >> Why not Hackers? Noone is a 'member' of anything except core or > >> mayber the web/infrastructure team. > > > > Define Hacker. And I could argue that some are members of PGDG. > > Says he who only the other day muttered something about how PGDG > wasn't a defined entity :-) I believe the term was "legal" entity (If it wasn't that is what I should of wrote). Which is true. We are however a "community". > > > What > > about those who provide just as much time and energy in advocacy as > > others do on -heackers? What about people that are working on > > external projects only such as Slony or PLproxy? > > The latter are still hackers using the definition we're likely to > agree on (ie. not a cracker). Both groups are 'Contributors' though. > Maybe just use 'Regular contributors' and 'Occasional contributors'. > Or major and minor. Or something entirely different. > Now that seems reasonable. Core Regular contributors Occasional contributors Past contributors Core and Regular should be on the same page. Occasional and Past on another? (At a minimum we can't have Past on the same page it would get too large). I don't like major and minor because a one line patch that saves someone from loosing all there data is a major contribution but we may never hear from the person again. Sincerely, Joshua D. Drake - -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240 PostgreSQL solutions since 1997 http://www.commandprompt.com/ UNIQUE NOT NULL Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHTZ3+ATb/zqfZUUQRAs0PAJ4nui/SBGaALAYQPGo5fN9SgQXnigCgpWGD t+lyk7oDx54Cz+6W4PjFwHI= =qsPR -END PGP SIGNATURE- ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] PG 7.3 is five years old today
Tom Lane wrote: > Gregory Stark <[EMAIL PROTECTED]> writes: >> Whether there's any need to support the old protocol in the server depends on >> whether there are any clients out there which use it which is harder to >> determine and not affected by whether Postgres 7.3 is still around. > > Right. There's really not much to be gained by dropping it on the > server side anyway. libpq might possibly be simplified by a useful > amount, but on the other hand we probably want to keep its current > structure for the inevitable v4 protocol. If we officially remove support for it, we could make modifications to it without having to consider V2 support. Not that I have any in the pipeline, but certainly it would make future changes easier if you don't have to consider backwards compatibility. Perhaps we could add a warnings message to the logs when a user connects using the v2 protocol for now, to give users fair warning? (and then drop it per 8.4). Or to take it even further, a guc that disables protocol v2 by default but can be enabled for users who are actually using it? > Another area where we might think about dropping some stuff is pg_dump. > If we got rid of the requirement to support dumps from pre-7.3 servers > then it could assume server-side dependencies exist, and lose all the > code for trying to behave sanely without 'em. That would certainly simplify it. There'd still be a supported upgrade path - just start by upgrading to 8.2 (or really, any supported version), *then* upgrade from that version to the latest one. That kind of required-step upgrade is fairly common with commercial products, and given how old 7.3 is I think it would be very acceptable. //Magnus ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] pgindent and multiline string constants
Peter Eisentraut <[EMAIL PROTECTED]> writes: > Somehow pgindent appears to do odd things with multiline string constants, > such as > somefunc(&blah, > "lots of text" > "with mulitple lines" > "like this"); > Afterwards this looks more like this: > somefunc(&blah, > "lots of text" > "with mulitple lines" >"like this"); Sometimes it does that to keep the lines from extending past column 80. I'm not sure that this is an improvement :-(, but anyway you can fix it by breaking the string literal into smaller chunks so that there's no line-wrapping going on in an 80-column view. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [pgsql-www] Time to update list of contributors
Joshua D. Drake wrote: > On Wed, 28 Nov 2007 16:53:43 + > Dave Page <[EMAIL PROTECTED]> wrote: > >> Joshua D. Drake wrote: >>> On Wed, 28 Nov 2007 16:27:42 + >>> Dave Page <[EMAIL PROTECTED]> wrote: >>> Why not Hackers? Noone is a 'member' of anything except core or mayber the web/infrastructure team. >>> Define Hacker. And I could argue that some are members of PGDG. >> Says he who only the other day muttered something about how PGDG >> wasn't a defined entity :-) > > I believe the term was "legal" entity (If it wasn't that is what I > should of wrote). Which is true. We are however a "community". > >>> What >>> about those who provide just as much time and energy in advocacy as >>> others do on -heackers? What about people that are working on >>> external projects only such as Slony or PLproxy? >> The latter are still hackers using the definition we're likely to >> agree on (ie. not a cracker). Both groups are 'Contributors' though. >> Maybe just use 'Regular contributors' and 'Occasional contributors'. >> Or major and minor. Or something entirely different. > > > Now that seems reasonable. > > Core > Regular contributors > Occasional contributors > Past contributors > > Core and Regular should be on the same page. > Occasional and Past on another? (At a minimum we can't have Past on > the same page it would get too large). Man, I'm glad I DB:ified that page a couple of months back :-P Do we really need separate pages, though? We already have the distinction that major developers (in your case, that would be Regular ones, I guess) are listed in full details, and other contributors are just listed with name. I still think we should keep "Hackers Emeritus" (you may rename it). The people on that list are way more than just "past contributors" IMHO. > I don't like major and minor because a one line patch that saves > someone from loosing all there data is a major contribution but we may > never hear from the person again. We don't generally add anybody who just provides a single patch, ever. They go in the release notes, but we only add people who've been around for a while to this list at all. I think, at least, but as has already been told there are no strict policies... //Magnus ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] String encoding during connection "handshake"
On 11/28/07, Martijn van Oosterhout <[EMAIL PROTECTED]> wrote: > On Wed, Nov 28, 2007 at 05:54:05PM +0200, [EMAIL PROTECTED] wrote: > > Regarding the problem of "One True Encoding", the answer seems obvious to > > me: > > use only one encoding per database cluster, either UTF-8 or UTF-16 or > > another > > Unicode-aware scheme, whichever yields a statistically smaller database for > > the languages employed by the users in their data. This encoding should be a > > one time choice! De facto, this is already happening now, because one cannot > > change collation rules after a cluster has been created. > Umm, each database in a cluster can have a different encoding, so there > is no such thing as the "cluster's encoding". You can certainly argue > that it should be a one time choice, but I doubt you'll get people to > remove the possibilites we have now. If fact, if anything we'd probably > go the otherway, allow you to select the collation on a per > database/table/column level (SQL complaince requires this). To be clear, what sulfinu is really advocating is convergence on Unicode period, which is the direction most international projects are moving, when they can. PostgreSQL's problem is that it (and AFAICT POSIX) conflates encoding with locale, when the two are entirely separate concepts. I'm not entirely sure how that's supposed to solve the client authentication issue though. Demanding that clients present auth data in UTF-8 is no different than demanding they present it in the encoding it was entered in originally... ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [pgsql-www] [HACKERS] Time to update list of contributors
Kris Jurka wrote: > > > On Tue, 27 Nov 2007, Josh Berkus wrote: > >> Kris Jurka, Finland > > USA actually. Where in the US? We generally list at least the state for ppl int he US - most often both city+state. (shows up only for people listed as major developers for the time being, which is why nobody asked for it before) //Magnus ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [pgsql-www] Time to update list of contributors
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 28 Nov 2007 18:34:57 +0100 Magnus Hagander <[EMAIL PROTECTED]> wrote: > > Now that seems reasonable. > > > > Core > > Regular contributors > > Occasional contributors > > Past contributors > > > > Core and Regular should be on the same page. > > Occasional and Past on another? (At a minimum we can't have Past on > > the same page it would get too large). > > Man, I'm glad I DB:ified that page a couple of months back :-P Me too... I wasn't looking forward to writing the patch ;) > > Do we really need separate pages, though? We already have the > distinction that major developers (in your case, that would be Regular > ones, I guess) are listed in full details, and other contributors are > just listed with name. I would be fine with that. > > I still think we should keep "Hackers Emeritus" (you may rename it). > The people on that list are way more than just "past contributors" > IMHO. *shrug* I don't really have a better name and I agree that we should give props so... Core Regular contributors Hackers Emeritus Occasional contributors Past contributors ??? > > > > I don't like major and minor because a one line patch that saves > > someone from loosing all there data is a major contribution but we > > may never hear from the person again. > > We don't generally add anybody who just provides a single patch, ever. > They go in the release notes, but we only add people who've been > around for a while to this list at all. I think, at least, but as has > already been told there are no strict policies... Fair enough but I think the point is still relevant, in that we really don't want to state specifically what a "Major" contributor is, I think it opens us up to more bad mojo than just saying you are either a regular contributor, or not :) Sincerely, Joshua D. Drake - -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240 PostgreSQL solutions since 1997 http://www.commandprompt.com/ UNIQUE NOT NULL Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHTakTATb/zqfZUUQRAjVDAJ4qhlxToVRJ25jn0pumr9u4ZgX1tQCglFrv FY3HgczRhQwqzDcHPJuA5xk= =s+FQ -END PGP SIGNATURE- ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] jaguar is up
[EMAIL PROTECTED] writes: > Jaguar is a new animal meant to test specific defines as asked by Tom > sometime ago. > Right now, it compiles and runs with -DCLOBBER_CACHE_ALWAYS Cool, how long does it take to run the regression tests? > Let me know if you want me to add/change flags Awhile back I got burnt by a gap in that testing methodology: http://archives.postgresql.org/pgsql-committers/2006-12/msg00237.php I didn't do anything about it at the time, but now I am tempted to modify LookupOpclassInfo() so that CLOBBER_CACHE_ALWAYS disables its internal cache. Any objections? regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] pgindent and multiline string constants
Tom Lane wrote: > Peter Eisentraut <[EMAIL PROTECTED]> writes: > > Somehow pgindent appears to do odd things with multiline string constants, > > such as > > > somefunc(&blah, > > "lots of text" > > "with mulitple lines" > > "like this"); > > > Afterwards this looks more like this: > > > somefunc(&blah, > > "lots of text" > > "with mulitple lines" > >"like this"); > > Sometimes it does that to keep the lines from extending past column 80. > I'm not sure that this is an improvement :-(, but anyway you can fix it > by breaking the string literal into smaller chunks so that there's no > line-wrapping going on in an 80-column view. Yes, I talked to Peter via IM on this. A good example is xml.c::3033 that looks like this: appendStringInfo(&result, " \n" "\n" "\n" " \n", (((uint64) 1) << (sizeof(int64) * 8 - 1)) - 1, (((uint64) 1) << (sizeof(int64) * 8 - 1))); The problem is that the lines with INT64_FORMAT are shifted to the left to be < 80 characters. What is really odd is line 3071 where the first and third quote lines are short enough to shift to the left, while the second line is so long that it doesn't to shift it at all: appendStringInfo(&result, " \n" "\n" " \n", typmod - VARHDRSZ, tz); Not sure what we can do to improve pgindent in this area. It treats these strings like function parameters, trying to keep them <80. -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] String encoding during connection "handshake"
On Wednesday 28 November 2007, Trevor Talbot wrote: > I'm not entirely sure how that's supposed to solve the client > authentication issue though. Demanding that clients present auth data > in UTF-8 is no different than demanding they present it in the > encoding it was entered in originally... Oh no, it's a big difference: PREDICTABILITY! Why must I guess the encoding used by the administrator? What if he's Chinese? Instead, I know the cluster's encoding, just as I know the server name and the TCP port. And the connection handshake carries on without misunderstandings (read wrong encoding). ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [pgsql-www] Time to update list of contributors
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 28 Nov 2007 13:15:52 -0500 Andrew Dunstan <[EMAIL PROTECTED]> wrote: > > > Joshua D. Drake wrote: > >Committers <-- this is obvious the only question is it only > > committers to the source tree or do we want to give equal billing to > > the -www guys (I think yes to equal billing) > > > > > > I don't have a problem with that, but I think core code committers > and www maintainers should be indentified separately. Why? Then we have to also separate advocacy which is just as important and pgfoundry... as well as possibly a host of others. We all have our job in the community :). > On a closely > related note: last time I looked there was no way for anyone to > discover on the web site who the committers actually are. That would > also probably be useful. See Dave's response about core not wanting committers that easily identified. I actually recall this argument, basically there are times when commit access might be revoked temporarily etc... IIRC.. Sincerely, Joshua Drake - -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240 PostgreSQL solutions since 1997 http://www.commandprompt.com/ UNIQUE NOT NULL Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHTbGmATb/zqfZUUQRAucRAJ9Xc3Rg7/rbyKD2BjuKJDOeIQaYBwCfbH31 xuLvWYGSfuM7O1DnI8HHK4k= =SrRN -END PGP SIGNATURE- ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] jaguar is up
On Wed, 28 Nov 2007, Tom Lane wrote: > Date: Wed, 28 Nov 2007 12:45:30 -0500 > From: Tom Lane <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Cc: pgsql-hackers list > Subject: Re: [HACKERS] jaguar is up > > [EMAIL PROTECTED] writes: > > Jaguar is a new animal meant to test specific defines as asked by Tom > > sometime ago. > > > Right now, it compiles and runs with -DCLOBBER_CACHE_ALWAYS > > Cool, how long does it take to run the regression tests? > The whole thing is about 96 Min, did'nt check the exact time of regression tests but it's long on a dual core AMD centos 5.0 sata disk system > > Let me know if you want me to add/change flags > > Awhile back I got burnt by a gap in that testing methodology: > http://archives.postgresql.org/pgsql-committers/2006-12/msg00237.php > > I didn't do anything about it at the time, but now I am tempted to > modify LookupOpclassInfo() so that CLOBBER_CACHE_ALWAYS disables > its internal cache. Any objections? > Nope! > regards, tom lane > Tell me if you want me to set up other tests or change configure param. Best regards -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [pgsql-www] Time to update list of contributors
>>> On Wed, Nov 28, 2007 at 11:34 AM, in message <[EMAIL PROTECTED]>, Magnus Hagander <[EMAIL PROTECTED]> wrote: > We don't generally add anybody who just provides a single patch, ever. > They go in the release notes, but we only add people who've been around > for a while to this list at all. I'm not sure what the point of the list is, but I had assumed that one reason for publishing it was to show the scope of the community. Wouldn't advocacy be better served by listing all the contributors, even those who have contributed for the first time in that release? Is there some risk there that I'm missing, a matter of the effort to gather the information, or to avoid offending more regular contributors? -Kevin ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] String encoding during connection "handshake"
On 11/28/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > On Wednesday 28 November 2007, Trevor Talbot wrote: > > I'm not entirely sure how that's supposed to solve the client > > authentication issue though. Demanding that clients present auth data > > in UTF-8 is no different than demanding they present it in the > > encoding it was entered in originally... > Oh no, it's a big difference: PREDICTABILITY! > Why must I guess the encoding used by the administrator? What if he's Chinese? > Instead, I know the cluster's encoding, just as I know the server name and > the TCP port. And the connection handshake carries on without > misunderstandings (read wrong encoding). What if the user and client program is Chinese too? Not everything is developed in an environment where UTF-8 support is easily available. Either way, it is a demand on the client, and not necessarily a simple one. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [pgsql-www] Time to update list of contributors
Joshua D. Drake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 28 Nov 2007 13:15:52 -0500 Andrew Dunstan <[EMAIL PROTECTED]> wrote: Joshua D. Drake wrote: Committers <-- this is obvious the only question is it only committers to the source tree or do we want to give equal billing to the -www guys (I think yes to equal billing) I don't have a problem with that, but I think core code committers and www maintainers should be indentified separately. Why? Then we have to also separate advocacy which is just as important and pgfoundry... as well as possibly a host of others. We all have our job in the community :). You are being overly sensitive. I never suggested otherwise. I simply suggested that the roles people do in fact play should be public. On a closely related note: last time I looked there was no way for anyone to discover on the web site who the committers actually are. That would also probably be useful. See Dave's response about core not wanting committers that easily identified. I actually recall this argument, basically there are times when commit access might be revoked temporarily etc... IIRC.. When I was made a committer, someone, I forget who, but I'm fairly sure it was some member of core, told me explicitly that it was intended to assist me professionally (and it has). That seems strangely at odds with a reluctance to publish the list of names of committers. It's not something I care deeply about, but it seems more than strange given that the list of active committers at least is not too hard to discover. cheers andrew ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [pgsql-www] Time to update list of contributors
Joshua D. Drake wrote: Committers <-- this is obvious the only question is it only committers to the source tree or do we want to give equal billing to the -www guys (I think yes to equal billing) I don't have a problem with that, but I think core code committers and www maintainers should be indentified separately. On a closely related note: last time I looked there was no way for anyone to discover on the web site who the committers actually are. That would also probably be useful. cheers andrew ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] String encoding during connection "handshake"
On Wednesday 28 November 2007, Alvaro Herrera wrote: > [EMAIL PROTECTED] escribió: > > Martijn, > > > > :) don't take it personal, I am just trying to obtain confirmation that I > > > > understood well the problem. Afterall, it's just that C has a very > > outdated notion of "char"s (and no notion of Unicode). I was naively > > under the impression that "char"s have evolved in nowadays C. > > This is not the language's fault in any way. We support plenty of > encodings beyond UTF-8. Yes, you support (and worry about) encodings simply because of a C limitation dating from 1974, if I recall correctly... In Java, for example, a "char" is a very well defined datum, namely a Unicode point. While in C it can be some char or another (or an error!) depending on what encoding was used. The only definition that stands up is that a "char" is a byte. Its interpretation is unsure and unsafe (see my original problem). On Wednesday 28 November 2007, Martijn van Oosterhout wrote: > On Wed, Nov 28, 2007 at 05:54:05PM +0200, [EMAIL PROTECTED] wrote: > > Regarding the problem of "One True Encoding", the answer seems obvious to > > me: use only one encoding per database cluster, either UTF-8 or UTF-16 or > > another Unicode-aware scheme, whichever yields a statistically smaller > > database for the languages employed by the users in their data. This > > encoding should be a one time choice! De facto, this is already happening > > now, because one cannot change collation rules after a cluster has been > > created. > > Umm, each database in a cluster can have a different encoding, so there > is no such thing as the "cluster's encoding". I implied that a cluster should have a single encoding that covers the whole Unicode set. That would certainly satisfy everybody. > You can certainly argue > that it should be a one time choice, but I doubt you'll get people to > remove the possibilites we have now. If fact, if anything we'd probably > go the otherway, allow you to select the collation on a per > database/table/column level (SQL complaince requires this). The collation order is implemented in close relationship with the byte representation of strings, but conceptually depends on the locale solely and has nothing to do with the encoding. > This has nothing to do with C by the way. C has many features that > allow you to work with different encodings. It just doesn't force you > to use any particular one. Yes, my point exactly! C forces you to worry about encoding. I mean, if you're not an ASCII-only user ;) Think of it this way: if I give you a Java String you will perfectly know what I meant; if I send you a C char* you don't know what it is in the absence of extra information - you can even use it as a uint8*, as it is actually done in md5.c. I consider this matter closed from my point of view and I have modified the JDBC driver according to my needs. Thank you all for the help. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [GENERAL] plperl and regexps with accented characters - incompatible?
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Just as a followup, I reported this as a bug and it is being looked at and discussed: http://rt.perl.org/rt3//Public/Bug/Display.html?id=47576 Appears there is no easy resolution yet. - -- Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200711281358 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iD8DBQFHTbpxvJuQZxSWSsgRA+BqAJ9Q1KB6w4ow7GyqXTY3EtZvJRrdkgCfVXlb yC/EaTWPOI6SpvBSRBXTC7s= =LA+E -END PGP SIGNATURE- ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [pgsql-www] Time to update list of contributors
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 28 Nov 2007 12:33:52 -0600 "Kevin Grittner" <[EMAIL PROTECTED]> wrote: > >>> On Wed, Nov 28, 2007 at 11:34 AM, in message > >>> <[EMAIL PROTECTED]>, > Magnus Hagander <[EMAIL PROTECTED]> wrote: > > > We don't generally add anybody who just provides a single patch, > > ever. They go in the release notes, but we only add people who've > > been around for a while to this list at all. > > I'm not sure what the point of the list is, but I had assumed that > one reason for publishing it was to show the scope of the community. > Wouldn't advocacy be better served by listing all the contributors, > even those who have contributed for the first time in that release? > > Is there some risk there that I'm missing, a matter of the effort > to gather the information, or to avoid offending more regular > contributors? Well to me, it is to acknowledge active community members which can be used as a tool for advocacy. A list that contains 3000 names does no one any good, we might as well just dump the mailing list subscribers :). However a reasonably managed list that shows strength in not only numbers but a solid base of frequent contributors, show duration and maturity within the project. Sincerely, Joshua D. Drake > > -Kevin > > > > > ---(end of > broadcast)--- TIP 7: You can help support the > PostgreSQL project by donating at > > http://www.postgresql.org/about/donate > - -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240 PostgreSQL solutions since 1997 http://www.commandprompt.com/ UNIQUE NOT NULL Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHTbX9ATb/zqfZUUQRAkLRAJ0Z7tuxKPA1iBvI2I3l7Yvp10tl5QCgjFaO PEMjG6fWqdqXMY1RPnzWMhY= =ISYJ -END PGP SIGNATURE- ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [pgsql-www] Time to update list of contributors
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 28 Nov 2007 13:50:02 -0500 Andrew Dunstan <[EMAIL PROTECTED]> wrote: > You are being overly sensitive. I never suggested otherwise. I simply > suggested that the roles people do in fact play should be public. And I was only pointing to a logistical problem with that thought process. You are a hacker, you are also a pgfoundry admin and buildfarm maintainer... Which list would you like to be under? Joshua D. Drake P.S. I know that answer, that isn't the point. - -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240 PostgreSQL solutions since 1997 http://www.commandprompt.com/ UNIQUE NOT NULL Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHTbnnATb/zqfZUUQRAuIQAJ0fA5EEywJYT9dT2ymR2dzpDNvuigCdHAE2 oM8Byrl8TbB0P/Z6AcnFU1g= =hLFJ -END PGP SIGNATURE- ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] String encoding during connection "handshake"
<[EMAIL PROTECTED]> writes: > Yes, you support (and worry about) encodings simply because of a C limitation > dating from 1974, if I recall correctly... > In Java, for example, a "char" is a very well defined datum, namely a Unicode > point. While in C it can be some char or another (or an error!) depending on > what encoding was used. No, you're being confused by C's idiosyncratic terminology. "char" in C just means 1-byte integral data type. If you want to store a unicode code point you use a different data type. Incidentally I'm not sure but I don't think it's true that "char" in Java stores a unicode code point. I thought Java used UTF16 internally for strings and strings stored arrays of chars. In which case "char" in Java stores two bytes of a UTF16 encoded string which is pretty analogous to storing UTF8 encoded strings in C where each "char" stores one byte of a UTF8 encoded string. > Think of it this way: if I give you a Java String you will perfectly know > what > I meant; if I send you a C char* you don't know what it is in the absence of > extra information - you can even use it as a uint8*, as it is actually done > in md5.c. That's because you're comparing apples to oranges. In C you don't even know if a char* is a string at all. It's a pointer to some bytes and those could contain anything. And think about what happens in Java if you have to deal with UTF8 encoded strings or Big5 encoded strings. They aren't "strings" in the Java object hierarchy so when someone passes you a "MyString" you have the same problems of needing to know what encoding was used. Presumably you would put that in a member variable of the MyString class but that just goes to how the data structures in C are laid out and what you're considering "extra information". -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication support! ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [pgsql-www] Time to update list of contributors
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Wednesday, November 28, 2007 08:20:04 -0800 "Joshua D. Drake" <[EMAIL PROTECTED]> wrote: >Core <-- this is obvious >Committers <-- this is obvious the only question is it only > committers to the source tree or do we want to give equal billing to > the -www guys (I think yes to equal billing) Equal billing, but categorized ... for instance, Dave Page might be something like: Dave Page (core, www) (where core reflects core server, not Core member) >Hacker Emeritus Past contributions? Most definitely ... - Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHTbxS4QvfyHIvDvMRAq4sAKDoUAhKsrHYPys7oeLyexUMyzHXewCffvZI D9i/ZWv84u5LBoXbSSv1ywI= =gBvn -END PGP SIGNATURE- ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [pgsql-www] Time to update list of contributors
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 28 Nov 2007 15:06:58 -0400 "Marc G. Fournier" <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > > - --On Wednesday, November 28, 2007 08:20:04 -0800 "Joshua D. Drake" > <[EMAIL PROTECTED]> wrote: > > >Core <-- this is obvious > >Committers <-- this is obvious the only question is it only > > committers to the source tree or do we want to give equal billing to > > the -www guys (I think yes to equal billing) > > Equal billing, but categorized ... for instance, Dave Page might be > something like: > > Dave Page (core, www) (where core reflects core server, not Core > member) I am trying to make an evolutionary step that will work within the existing infrastructure. Based on Magnus's reply my solution requires heading changes and moving names around without anything else. Sincerely, Joshua D. Drake - -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240 PostgreSQL solutions since 1997 http://www.commandprompt.com/ UNIQUE NOT NULL Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHTb1vATb/zqfZUUQRAmDtAJ4pJjKr/b1p+2bnZ6TW/hQgaZ2VTQCgoz9r 0nrCvbM+2bXpSG3jU8AKFrg= =JupM -END PGP SIGNATURE- ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [pgsql-www] Time to update list of contributors
Marc G. Fournier wrote: > > > --On Wednesday, November 28, 2007 08:20:04 -0800 "Joshua D. Drake" > <[EMAIL PROTECTED]> wrote: > >>Core <-- this is obvious >>Committers <-- this is obvious the only question is it only >> committers to the source tree or do we want to give equal billing to >> the -www guys (I think yes to equal billing) > > Equal billing, but categorized ... for instance, Dave Page might be something > like: > > Dave Page (core, www) (where core reflects core server, not Core member) erm ? last i looked dave seemed to be a core member but not a (core) commiter ? :-) Stefan ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [pgsql-www] Time to update list of contributors
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 28 Nov 2007 14:16:16 -0500 (EST) Bruce Momjian <[EMAIL PROTECTED]> wrote: > > I believe the reason we don't publicize who is a committer is that > > we have non-committers who do a lot more for the project. Commit > > rights are usually given to people who do a lot of patches (perhaps > > small ones) while people who develop larger patches are less likely > > to get commit rights rapidly. > > Of course the next question is why core is split out, especially since > core's role is mostly for confidential company contacts and > discipline. *shrug* I have always considered core a steering committee type of deal. Not "in charge" persay but there as a focal point when needed (like the name change decision that was finally made). It seems to me that it makes sense, based on that to break it out. However there is another consideration in that at least two core members seem to have zero interest in being involved in a very public way like you suggest above. So perhaps it makes sense for core to be inclusive of the list and instead push all "contacts" to a contacts page. Sincerely, Joshua D. Drake - -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240 PostgreSQL solutions since 1997 http://www.commandprompt.com/ UNIQUE NOT NULL Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHTb9OATb/zqfZUUQRArpyAJ9H4ANMkcYvvQ/EkmL9ZySSM1PNJQCfaEFi kEFgzu+0FjRgA+i2RdxbxIE= =BGTr -END PGP SIGNATURE- ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [pgsql-www] Time to update list of contributors
Bruce Momjian wrote: > Joshua D. Drake wrote: > > > I don't have a problem with that, but I think core code committers > > > and www maintainers should be identified separately. > > > > Why? Then we have to also separate advocacy which is just as important > > and pgfoundry... as well as possibly a host of others. We all have our > > job in the community :). > > > > > On a closely > > > related note: last time I looked there was no way for anyone to > > > discover on the web site who the committers actually are. That would > > > also probably be useful. > > > > See Dave's response about core not wanting committers that easily > > identified. I actually recall this argument, basically there are times > > when commit access might be revoked temporarily etc... IIRC.. > > I believe the reason we don't publicize who is a committer is that we > have non-committers who do a lot more for the project. Commit rights > are usually given to people who do a lot of patches (perhaps small ones) > while people who develop larger patches are less likely to get commit > rights rapidly. Of course the next question is why core is split out, especially since core's role is mostly for confidential company contacts and discipline. -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [pgsql-www] Time to update list of contributors
Joshua D. Drake wrote: > > I don't have a problem with that, but I think core code committers > > and www maintainers should be indentified separately. > > Why? Then we have to also separate advocacy which is just as important > and pgfoundry... as well as possibly a host of others. We all have our > job in the community :). > > > On a closely > > related note: last time I looked there was no way for anyone to > > discover on the web site who the committers actually are. That would > > also probably be useful. > > See Dave's response about core not wanting committers that easily > identified. I actually recall this argument, basically there are times > when commit access might be revoked temporarily etc... IIRC.. I believe the reason we don't publicise who is a committer is that we have non-committers who do a lot more for the project. Commit rights are usually given to people who do a lot of patches (perhaps small ones) while people who develop larger patches are less likely to get commit rights rapidly. -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] String encoding during connection "handshake"
On 11/28/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Yes, you support (and worry about) encodings simply because of a C limitation > dating from 1974, if I recall correctly... > In Java, for example, a "char" is a very well defined datum, namely a Unicode > point. While in C it can be some char or another (or an error!) depending on > what encoding was used. The only definition that stands up is that a "char" > is a byte. Its interpretation is unsure and unsafe (see my original problem). It's not really that simple. Java, for instance, does not actually support Unicode characters / codepoints at the base level; it merely deals in UTF-16 code units. (The critical difference is in surrogate pairs.) You're still stuck dealing with a specific encoding even in many modern languages. PostgreSQL's encoding support is not just about languages though, it's also about client convenience. It could simply choose a single encoding and parrot data to and from the client, but it also does on-the-fly conversion when a client requests it. It's a very useful feature, and many mature networked applications support similar things. An easy example is the World Wide Web itself. > I implied that a cluster should have a single encoding that covers the whole > Unicode set. That would certainly satisfy everybody. Note that it might not. Unicode does not encode *every* character, and in some cases there is no round-trip mapping between it and other character sets. The result could be a loss of semantic data. I suspect it actually would satisfy everyone in PostgreSQL's case, but it's not something you can assume without checking. > > This has nothing to do with C by the way. C has many features that > > allow you to work with different encodings. It just doesn't force you > > to use any particular one. > Yes, my point exactly! C forces you to worry about encoding. I mean, if you're > not an ASCII-only user ;) For a networked application, you're stuck worrying about the encoding regardless of language. UTF-8 is the most common Internet transport, for instance, but that's not the native internal encoding used by Java and most other Unicode processing platforms to date. That's fairly simple since it's still only a single character set, but if your application domain predates Unicode, you can't avoid dealing with the legacy encodings at some level anyway. As I implied earlier, I do think it would be worthwhile for PostgreSQL to move toward handling it better, so I'm not saying this is a bad idea. It's just that it's a much more complex topic than it might seem at first glance. I'm glad you got something working for you. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [GENERAL] plperl and regexps with accented characters - incompatible?
Greg Sabino Mullane wrote: Just as a followup, I reported this as a bug and it is being looked at and discussed: http://rt.perl.org/rt3//Public/Bug/Display.html?id=47576 Appears there is no easy resolution yet. We might be able to do something with the suggested workaround. I will see what I can do, unless you have already tried. cheers andrew ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [pgsql-www] Time to update list of contributors
Dave, > Hiroshi Saito has made a number of smaller but important contributions > this cycle. Thanks. I was being surprised to see only one Japanese contributor this cycle. > Heikki is from Finland, but currently living in the UK. Thanks! > You also missed my name despite it being attributed to 3 items in the > release notes, but I don't suppose that matters as I'm in the core > section anyway. Damn. I think I kept skipping it because I thought I'd already put it in. I'll bet I missed another core member too. -- Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] quotas once again
Sometime ago there was a discussion about user/database quota and IIRC there was also some patch for this (probably got rejected). Does anyone know to which direction we went for having quotas? Regards, Gevik Gevik Babakhani PostgreSQL NL http://www.postgresql.nl TrueSoftware BV http://www.truesoftware.nl ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] String encoding during connection "handshake"
On Wed, 28 Nov 2007, [EMAIL PROTECTED] wrote: I consider this matter closed from my point of view and I have modified the JDBC driver according to my needs. Could you explain in more detail what you've done to the JDBC driver in case it is generally useful or other people have the same problem? Kris Jurka ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgsql-www] [HACKERS] Time to update list of contributors
On Wednesday 28 November 2007 04:21, Magnus Hagander wrote:
> On Tue, Nov 27, 2007 at 04:08:36PM -0800, Josh Berkus wrote:
> > All,
> >
> > Time for the annual update of this list:
> > http://www.postgresql.org/developer/bios
> >
> > Here's the list of people I gleaned from the release notes (btw, if
> > people have countries for the folks who aren't attributed, I'd appreciate
> > them). Of course, there are many contributors to essential non-core code
> > who should be listed as well:
>
> The mentioned page has a split in "core", "major" and "other" developers.
> The first part is easy, but a difference is needed between the other two I
> think.
>
A major contributor is differentiated from other contributors based on 1)
longevity in the community, 2) number of areas they work on, 3) signifigance
of the contributions that have been made.
To become an other contributor, you have to have contributed something of
sginifcance to the community; this has typically meant some new feature for a
release, but could also mean being a package maintainer for one of the open
source platforms; it was something specific to the postgresql core project
though; ie. something likely discussed on the postgresql mailing lists, or
involving the central project.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [GENERAL] plperl and regexps with accented characters - incompatible?
Andrew Dunstan wrote:
Greg Sabino Mullane wrote:
Just as a followup, I reported this as a bug and it is being looked
at and discussed:
http://rt.perl.org/rt3//Public/Bug/Display.html?id=47576
Appears there is no easy resolution yet.
We might be able to do something with the suggested workaround. I will
see what I can do, unless you have already tried.
OK, I have a fairly ugly manual workaround, that I don't yet understand,
but seems to work for me.
In your session, run the following code before you do anything else:
CREATE OR REPLACE FUNCTION test((text) RETURNS bool LANGUAGE plperl as $$
return shift =~ /\xa9/i ? 'true' : 'false';
$$;
SELECT test('a');
DROP FUNCTION test(text);
After that we seem to be good to go with any old UTF8 chars.
I'm looking at automating this so the workaround can be hidden, but I'd
rather understand it first.
(Core guys: If we can hold RC1 for a bit while I get this fixed that
would be good.)
cheers
andrew
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] developing for psqlodbc
Hi, On Mon, 2007-11-26 at 18:01 -0800, John Walker wrote: > i'd like to try to develop some improvements to psqlodbc. For development of psqlodbc, please subscribe and post to pgsql-odbc list. Regards, -- Devrim GÜNDÜZ , RHCE PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/ signature.asc Description: This is a digitally signed message part
Re: [HACKERS] quotas once again
Hello this patch was commited http://archives.postgresql.org/pgsql-committers/2007-11/msg00530.php Regards Pavel Stehule On 28/11/2007, Gevik Babakhani <[EMAIL PROTECTED]> wrote: > Sometime ago there was a discussion about user/database quota and > IIRC there was also some patch for this (probably got rejected). > > Does anyone know to which direction we went for having quotas? > > Regards, > Gevik > > Gevik Babakhani > > PostgreSQL NL http://www.postgresql.nl > TrueSoftware BV http://www.truesoftware.nl > > > > ---(end of broadcast)--- > TIP 1: if posting/reading through Usenet, please send an appropriate >subscribe-nomail command to [EMAIL PROTECTED] so that your >message can get through to the mailing list cleanly > ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] quotas once again
Pavel Stehule wrote: > Hello > > this patch was commited > > http://archives.postgresql.org/pgsql-committers/2007-11/msg00530.php Uh, he was asking about "quotas", not "quotes". No, we don't have user quotas yet. --- > > Regards > Pavel Stehule > > On 28/11/2007, Gevik Babakhani <[EMAIL PROTECTED]> wrote: > > Sometime ago there was a discussion about user/database quota and > > IIRC there was also some patch for this (probably got rejected). > > > > Does anyone know to which direction we went for having quotas? > > > > Regards, > > Gevik > > > > Gevik Babakhani > > > > PostgreSQL NL http://www.postgresql.nl > > TrueSoftware BV http://www.truesoftware.nl > > > > > > > > ---(end of broadcast)--- > > TIP 1: if posting/reading through Usenet, please send an appropriate > >subscribe-nomail command to [EMAIL PROTECTED] so that your > >message can get through to the mailing list cleanly > > > > ---(end of broadcast)--- > TIP 3: Have you checked our extensive FAQ? > >http://www.postgresql.org/docs/faq -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] quotas once again
On 28/11/2007, Bruce Momjian <[EMAIL PROTECTED]> wrote: > Pavel Stehule wrote: > > Hello > > > > this patch was commited > > > > http://archives.postgresql.org/pgsql-committers/2007-11/msg00530.php > > Uh, he was asking about "quotas", not "quotes". No, we don't have user > quotas yet. > I am blind. I am sorry. Its too late Pavel > --- > > > > > > > Regards > > Pavel Stehule > > > > On 28/11/2007, Gevik Babakhani <[EMAIL PROTECTED]> wrote: > > > Sometime ago there was a discussion about user/database quota and > > > IIRC there was also some patch for this (probably got rejected). > > > > > > Does anyone know to which direction we went for having quotas? > > > > > > Regards, > > > Gevik > > > > > > Gevik Babakhani > > > > > > PostgreSQL NL http://www.postgresql.nl > > > TrueSoftware BV http://www.truesoftware.nl > > > > > > > > > > > > ---(end of broadcast)--- > > > TIP 1: if posting/reading through Usenet, please send an appropriate > > >subscribe-nomail command to [EMAIL PROTECTED] so that your > > >message can get through to the mailing list cleanly > > > > > > > ---(end of broadcast)--- > > TIP 3: Have you checked our extensive FAQ? > > > >http://www.postgresql.org/docs/faq > > -- > Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us > EnterpriseDB http://postgres.enterprisedb.com > > + If your life is a hard drive, Christ can be your backup. + > ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] quotas once again
> Uh, he was asking about "quotas", not "quotes". No, we don't > have user quotas yet. > Thank you. I read we have a "Allow per-tablespace quotas". But the more I think about this the more complex it gets. I guess implementing a user quota is a very different story than quotas per-tablespace. Gevik Babakhani PostgreSQL NL http://www.postgresql.nl TrueSoftware BV http://www.truesoftware.nl > > > > > > Regards > > Pavel Stehule > > > > On 28/11/2007, Gevik Babakhani <[EMAIL PROTECTED]> wrote: > > > Sometime ago there was a discussion about user/database quota and > > > IIRC there was also some patch for this (probably got rejected). > > > > > > Does anyone know to which direction we went for having quotas? > > > > > > Regards, > > > Gevik > > > > > > Gevik Babakhani > > > > > > PostgreSQL NL http://www.postgresql.nl > > > TrueSoftware BV http://www.truesoftware.nl > > > > > > > > > > > > ---(end of > > > broadcast)--- > > > TIP 1: if posting/reading through Usenet, please send an > appropriate > > >subscribe-nomail command to > [EMAIL PROTECTED] so that your > > >message can get through to the mailing list cleanly > > > > > > > ---(end of > > broadcast)--- > > TIP 3: Have you checked our extensive FAQ? > > > >http://www.postgresql.org/docs/faq > > -- > Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us > EnterpriseDB > http://postgres.enterprisedb.com > > + If your life is a hard drive, Christ can be your backup. + > ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] PG 7.3 is five years old today
On Tue, 27 Nov 2007 15:37:04 -0500 Tom Lane wrote: > "Andreas 'ads' Scherbaum" <[EMAIL PROTECTED]> writes: > > On Tue, 27 Nov 2007 11:08:58 -0800 Joshua D. Drake wrote: > >> Release 7.3.21 with and EOL addendum :). E.g; this is the last release > >> of 7.3 and 7.3 is now considered unsupported. > > > I know at least one customer who is using RHEL-3 and PG 7.3 on dozens > > machines worldwide. > > Are they running 7.3.20? Will they update to 7.3.21 promptly when we > ship it? Or are they using whatever Red Hat includes in RHEL-3? > (which is still 7.3.19 I believe) I'm not sure, which micro version they are using right now. I only know, they have 7.3.x, cause i already had to take care of this on some projects. > One of the reasons for losing interest in frequent updates is that > it seems most of the people we hear from who are running 7.3.x are > running a pretty obsolete "x". If we produce an update and no one > actually installs it, we're just wasting time with make-work. I said: we should not disband support of 7.3 today, release a final version next week and that's it. Something like 3, 4 month of pre-announce seems to be ok for me and i don't think, this makes much difference. Kind regards -- Andreas 'ads' Scherbaum Failure is not an option. It comes bundled with your Microsoft product. (Ferenc Mantfeld) ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] PG 7.3 is five years old today
On Tue, 27 Nov 2007 23:53:14 -0500 Robert Treat wrote: > I also think we should be a bit more generous on the EOL notice. Saying one > more > update after 8.3 is akin to giving a 1 month EOL notice; not friendly at all > imo. Set it for July 2008 and I think you have given plenty of notice (and > given the lack of back patches, should be too much of a burden in that time > either) +1 for that. Kind regards -- Andreas 'ads' Scherbaum Failure is not an option. It comes bundled with your Microsoft product. (Ferenc Mantfeld) ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [pgsql-www] [HACKERS] Time to update list of contributors
Magnus Hagander wrote: Where in the US? We generally list at least the state for ppl int he US - most often both city+state. (shows up only for people listed as major developers for the time being, which is why nobody asked for it before) Denver, CO Kris Jurka ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] jaguar is up
"Tom Lane" <[EMAIL PROTECTED]> writes: > I didn't do anything about it at the time, but now I am tempted to > modify LookupOpclassInfo() so that CLOBBER_CACHE_ALWAYS disables > its internal cache. Any objections? That sounds not equivalent to receiving a relcache flush at any particular point in time where a relcache flush could be received. Wouldn't it make more sense (and test more code) to go ahead and cache all the same data but flush it whenever a relcache flush could possibly be received? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services! ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] quotas once again
Jonah H. Harris escribió: > On Nov 28, 2007 3:21 PM, Gevik Babakhani <[EMAIL PROTECTED]> wrote: > > Sometime ago there was a discussion about user/database quota and > > IIRC there was also some patch for this (probably got rejected). > > > > Does anyone know to which direction we went for having quotas? > > I had written a patch for user quotas back in 2004. While the patch > is probably long gone, if you're interested, I'd be willing to assist > in its development. Did you publish it in pgsql-patches? If so, it can be fished from there. -- Alvaro Herrera http://www.amazon.com/gp/registry/DXLWNGRJD34J "You're _really_ hosed if the person doing the hiring doesn't understand relational systems: you end up with a whole raft of programmers, none of whom has had a Date with the clue stick." (Andrew Sullivan) ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] quotas once again
On Nov 28, 2007 3:21 PM, Gevik Babakhani <[EMAIL PROTECTED]> wrote: > Sometime ago there was a discussion about user/database quota and > IIRC there was also some patch for this (probably got rejected). > > Does anyone know to which direction we went for having quotas? I had written a patch for user quotas back in 2004. While the patch is probably long gone, if you're interested, I'd be willing to assist in its development. -- Jonah H. Harris, Sr. Software Architect | phone: 732.331.1324 EnterpriseDB Corporation| fax: 732.331.1301 499 Thornall Street, 2nd Floor | [EMAIL PROTECTED] Edison, NJ 08837| http://www.enterprisedb.com/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] How to write a c-function to return multiple bytea rows
I can return multiple strings w/o problem.
But if I tried to return multiple bytea rows. It only return 10 rows with
empty data.
Please see the code below.
Also, when I compile it, I had warning:
test.c:121: warning: assignment makes pointer from integer without a cast
The line is:
tuple = heap_form_tuple( tupdesc, &dtvalues, &isNull );
Strange.. compiled in a linux box.
If I use: tuple = BuildTupleFromCStrings(attinmeta, values);
it can work but it's string and I want to use bytea.
Also, do I need to free char** values or let postgresql do the job?
Thanks
Billow
/
-- select * from test(1,2,'asdfdsaf') as (id bytea);
CREATE OR REPLACE FUNCTION test(int,int,text)
RETURNS setof record
AS 'gr_indexsearch.so', 'test'
LANGUAGE 'C' IMMUTABLE CALLED ON NULL INPUT;
*/
// PostgreSQL includes
#include "postgres.h"
#include "fmgr.h"
// Tuple building functions and macros
#include "funcapi.h"
#include "utils/builtins.h"
#include
#define _textout(str) DatumGetPointer(DirectFunctionCall1(textout,
PointerGetDatum(str)))
#ifndef SET_VARSIZE
#define SET_VARSIZE(v,l) (VARATT_SIZEP(v) = (l))
#endif
/* SortMem got renamed in PostgreSQL 8.0 */
#ifndef SortMem
#define SortMem 16 * 1024
#endif
#ifdef PG_MODULE_MAGIC
PG_MODULE_MAGIC;
#endif
// forward declaration to keep compiler happy
Datum c_complex_add( PG_FUNCTION_ARGS );
PG_FUNCTION_INFO_V1( test );
Datum test( PG_FUNCTION_ARGS )
{
// things we need to deal with constructing our composite type
TupleDesc tupdesc;
HeapTuple tuple;
Tuplestorestate *tupstore = NULL;
ReturnSetInfo *rsinfo = (ReturnSetInfo *) fcinfo->resultinfo;
MemoryContext per_query_ctx;
MemoryContext oldcontext;
// Get arguments. If we declare our function as STRICT, then
// this check is superfluous.
if( PG_ARGISNULL(0) ||
PG_ARGISNULL(1) ||
PG_ARGISNULL(2))
{
PG_RETURN_NULL();
}
// Get arguments: TimeStart and TimeEnd
int32 TimeStart = PG_GETARG_INT32(0);
int32 TimeEnd = PG_GETARG_INT32(1);
// Get Search query
char *query = _textout(PG_GETARG_TEXT_P(2));
/* check to see if caller supports us returning a tuplestore */
if (!rsinfo || !(rsinfo->allowedModes & SFRM_Materialize))
ereport(ERROR,
(errcode(ERRCODE_SYNTAX_ERROR),
errmsg("materialize mode required, but it is not " \
"allowed in this context")));
/* let the caller know we're sending back a tuplestore */
rsinfo->returnMode = SFRM_Materialize;
per_query_ctx = fcinfo->flinfo->fn_mcxt;
oldcontext = MemoryContextSwitchTo(per_query_ctx);
/* get the requested return tuple description */
tupdesc = rsinfo->expectedDesc;
/* OK, use it */
AttInMetadata *attinmeta = TupleDescGetAttInMetadata(tupdesc);
/* initialize our tuplestore */
tupstore = tuplestore_begin_heap(true, false, SortMem);
char strtest[] = "This is a test!";
int strleng = strlen(strtest);
int rows = 10;
//char** values = (char **) palloc(rows * sizeof(char *));
bytea** values = (bytea **) palloc(rows * sizeof(bytea *));
Datum dtvalues;
bool isNull;
int i;
for(i=0; isetResult = tupstore;
/*
* SFRM_Materialize mode expects us to return a NULL Datum. The actual
* tuples are in our tuplestore and passed back through
rsinfo->setResult.
* rsinfo->setDesc is set to the tuple description that we actually used
* to build our tuples with, so the caller can verify we did what it was
* expecting.
*/
rsinfo->setDesc = tupdesc;
MemoryContextSwitchTo(oldcontext);
return (Datum) 0;
}
Re: [HACKERS] quotas once again
On Nov 28, 2007 8:09 PM, Alvaro Herrera <[EMAIL PROTECTED]> wrote: > Did you publish it in pgsql-patches? If so, it can be fished from > there. Unfortunately, no. IIRC, I believe the topic moved to being non-user-based quotas and more tablespace-oriented. -- Jonah H. Harris, Sr. Software Architect | phone: 732.331.1324 EnterpriseDB Corporation| fax: 732.331.1301 499 Thornall Street, 2nd Floor | [EMAIL PROTECTED] Edison, NJ 08837| http://www.enterprisedb.com/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] How to write a c-function to return multiple bytea rows
I don't know if it's the proximate source of your problem but your MemoryContextSwitchTo() calls are mixed up. You're reusing the same oldcontext variable for both the switch you're doing in the main body and the switch you're doing in the inner loop. At the very least you should use two different oldcontext variables, currently I think you're leaving the memory context set to the per_query_ctx. But I think in this situation you're going to end up just doing the whole thing in per_query_ctx anyways. The only part you can avoid that for is the pallocing of the heap_form_tuple args and the actual heap_form_tuple call. The tuple will be copied when you call tuplestore_puttuple (which should be done in the same context the tuplestore was created in). -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training! ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] unclear enum error messages
On Nov 28, 2007 11:01 AM, Tom Lane <[EMAIL PROTECTED]> wrote: > > What is an actual enum type? And how should a user react if he got this > > message? I would ask, "why not?". > > Yeah, I would too, but without a concrete example to look at it's hard > to say if the situation could be improved. Hmm. I've just tried, unsuccessfully, to trigger that branch both calling those functions directly from psql and from plpython calling plpy.prepare() and passing bogus type info in. It's harder than it looks. I'm sure that there are code paths that will call those functions without filling out that type info (e.g. from C user defined function?), but they must surely fall outside of the expected use cases. Hence the error code is probably correct. Unsure about the message... we could make it extremely explicit e.g. "you're calling this without filling in fcinfo" but we'd want to be really sure that it's definitely only possible to trigger via user error before getting that detailed. I'm not sure that we're completely confident of that, so perhaps the vague-ish message is ok. I wouldn't get too worried, though. These are defensive error messages that are really just checking for sane input, and they seem difficult to deliberately trip, let alone accidentally, so stressing about them is probably unnecessary. Cheers Tom ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] unclear enum error messages
"Tom Dunstan" <[EMAIL PROTECTED]> writes: > I wouldn't get too worried, though. These are defensive error messages > that are really just checking for sane input, and they seem difficult > to deliberately trip, let alone accidentally, so stressing about them > is probably unnecessary. Right. I'm not really expecting to see that message fire; it's just there to ensure sane behavior if it does happen. Peter might be right that an elog instead of ereport would be sufficient. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [GENERAL] plperl and regexps with accented characters - incompatible?
Andrew Dunstan wrote:
Andrew Dunstan wrote:
Greg Sabino Mullane wrote:
Just as a followup, I reported this as a bug and it is being looked
at and discussed:
http://rt.perl.org/rt3//Public/Bug/Display.html?id=47576
Appears there is no easy resolution yet.
We might be able to do something with the suggested workaround. I
will see what I can do, unless you have already tried.
OK, I have a fairly ugly manual workaround, that I don't yet
understand, but seems to work for me.
In your session, run the following code before you do anything else:
CREATE OR REPLACE FUNCTION test(text) RETURNS bool LANGUAGE plperl as $$
return shift =~ /\xa9/i ? 'true' : 'false';
$$;
SELECT test('a');
DROP FUNCTION test(text);
After that we seem to be good to go with any old UTF8 chars.
I'm looking at automating this so the workaround can be hidden, but
I'd rather understand it first.
(Core guys: If we can hold RC1 for a bit while I get this fixed that
would be good.)
The attached patch works for me to eliminate the errors. Please test ASAP.
cheers
andrew
Index: src/pl/plperl/plperl.c
===
RCS file: /cvsroot/pgsql/src/pl/plperl/plperl.c,v
retrieving revision 1.132
diff -c -r1.132 plperl.c
*** src/pl/plperl/plperl.c 15 Nov 2007 22:25:17 - 1.132
--- src/pl/plperl/plperl.c 29 Nov 2007 05:32:22 -
***
*** 149,154
--- 149,156
static SV *newSVstring(const char *str);
static SV **hv_store_string(HV *hv, const char *key, SV *val);
static SV **hv_fetch_string(HV *hv, const char *key);
+ static SV *plperl_create_sub(char *proname, char *s, bool trusted);
+ static SV *plperl_call_perl_func(plperl_proc_desc *desc, FunctionCallInfo fcinfo);
/*
* This routine is a crock, and so is everyplace that calls it. The problem
***
*** 504,509
--- 506,558
else
{
eval_pv(SAFE_OK, FALSE);
+ if (GetDatabaseEncoding() == PG_UTF8)
+ {
+
+ /*
+ * Fill in just enough information to set up this perl
+ * function in the safe container and call it.
+ * For some reason not entirely clear, it prevents errors that
+ * can arise from the regex code later trying to load
+ * utf8 modules.
+ */
+
+ plperl_proc_desc desc;
+ FunctionCallInfoData fcinfo;
+ FmgrInfo outfunc;
+ HeapTuple typeTup;
+ Form_pg_type typeStruct;
+ SV *ret;
+ SV *func;
+
+ /* make sure we don't call ourselves recursively */
+ plperl_safe_init_done = true;
+
+ /* compile the function */
+ func = plperl_create_sub(
+ "utf8fix",
+ "return shift =~ /\\xa9/i ? 'true' : 'false' ;",
+ true);
+
+
+ /* set up to call the function with a single text argument 'a' */
+ desc.reference = func;
+ desc.nargs = 1;
+ desc.arg_is_rowtype[0] = false;
+ fcinfo.argnull[0] = false;
+ fcinfo.arg[0] =
+ DatumGetTextP(DirectFunctionCall1(textin,
+ CStringGetDatum("a")));
+ typeTup = SearchSysCache(TYPEOID,
+ TEXTOID,
+ 0, 0, 0);
+ typeStruct = (Form_pg_type) GETSTRUCT(typeTup);
+ fmgr_info(typeStruct->typoutput,&(desc.arg_out_func[0]));
+ ReleaseSysCache(typeTup);
+
+ /* and make the call */
+ ret = plperl_call_perl_func(&desc,&fcinfo);
+ }
}
plperl_safe_init_done = true;
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [HACKERS] jaguar is up
Gregory Stark <[EMAIL PROTECTED]> writes: > "Tom Lane" <[EMAIL PROTECTED]> writes: >> I didn't do anything about it at the time, but now I am tempted to >> modify LookupOpclassInfo() so that CLOBBER_CACHE_ALWAYS disables >> its internal cache. Any objections? > That sounds not equivalent to receiving a relcache flush at any particular > point in time where a relcache flush could be received. Wouldn't it make more > sense (and test more code) to go ahead and cache all the same data but flush > it whenever a relcache flush could possibly be received? CLOBBER_CACHE_ALWAYS already did that. I'm too lazy to go back and reconstruct the exact sequence of events that led to the problem last December, but the basic issue is that LookupOpclassInfo had its own caching in front of the syscache flush, and that was able to obscure a cache flush race condition that only happened when LookupOpclassInfo had to actually load data. If you really want to question this, I suggest loading up a CVS snapshot from late last December and trying to reproduce the intermittent buildfarm failures we were seeing then. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] How to write a c-function to return multiple bytea rows
"Billow Gao" <[EMAIL PROTECTED]> writes: > Also, when I compile it, I had warning: > test.c:121: warning: assignment makes pointer from integer without a cast > The line is: > tuple = heap_form_tuple( tupdesc, &dtvalues, &isNull ); That part is because you didn't #include access/heapam.h, where heap_form_tuple is declared. If you didn't get a warning about it not being declared, you do not have warnings turned up high enough. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] Re: [HACKERS] [GENERAL] plperl and regexps with accented characters - incompatible?
Andrew Dunstan <[EMAIL PROTECTED]> writes: > + * Fill in just enough information to set up this perl > + * function in the safe container and call it. > + * For some reason not entirely clear, it prevents > errors that > + * can arise from the regex code later trying to load > + * utf8 modules. How many versions of Perl have you tried this against? regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
