Re: [PATCHES] plperl features
Do we need a TODO item? --- Andrew Dunstan wrote: This was the patch that I took the array processing piece from and attempted to fix, since it was badly broken. However, I'm not happy about any of the ways of doing it, and suspect I won't get it done for 8.1. I think we need that piece done before we look at ANYELEMENT/ANYARRAY. cheers andrew Bruce Momjian wrote: Sergej, are you going to repost this patch? --- Tom Lane wrote: Bruce Momjian pgman@candle.pha.pa.us writes: Also, I don't think the arg_is_p variable is really the proper fix for this, but I am unsure what to recomment. Others? The thing I didn't like about that was that it assumes there is only one pseudotype behavior that is or ever will be interesting for plperl. I think it'd probably make more sense to store an array of the parameter type OIDs and then check for ANYELEMENT or ANYARRAY as such in the places where the patch uses arg_is_p. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: 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: [PATCHES] plperl features
Bruce Momjian wrote: Do we need a TODO item? Sure, Maybe two: . pass arrays natively instead of as text between plperl and postgres . add support for polymorphic arguments and return types to plperl cheers andrew ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] Add PG version number to NLS files
Peter Eisentraut [EMAIL PROTECTED] writes: Am Samstag, 25. Juni 2005 04:24 schrieb Bruce Momjian: We absolutely want to support multiple installed versions of PostgreSQL. But we don't support installing multiple versions on top of each other, which is the only scenario where this patch would be useful. I agree with Peter. AFAICS, the binaries go into $prefix/bin and the NLS files go into $prefix/share/locale, so there is no more nor less conflict among different versions' NLS files than their executables. In both cases the only supported way to have multiple installations at once is to use different install prefixes. So why complicate matters like this? regards, tom lane ---(end of broadcast)--- TIP 3: 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: [PATCHES] Add PG version number to NLS files
Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: Am Samstag, 25. Juni 2005 04:24 schrieb Bruce Momjian: We absolutely want to support multiple installed versions of PostgreSQL. But we don't support installing multiple versions on top of each other, which is the only scenario where this patch would be useful. I agree with Peter. AFAICS, the binaries go into $prefix/bin and the NLS files go into $prefix/share/locale, so there is no more nor less conflict among different versions' NLS files than their executables. In both cases the only supported way to have multiple installations at once is to use different install prefixes. So why complicate matters like this? OK. I guess I am confused. Right now bindtextdomain() just calls something like bindtextdomain(libpq), etc. How does it know to use the proper share/locale? And is bindtextdomain(psql) different? I am just trying to understand how things work. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: 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
