Re: [HACKERS] compiling postgres with Visual Age compiler on OpenPower5 / Linux
> I have not researched any deeper,but currently it fails with > > [EMAIL PROTECTED] postgresql-8.0.3]$ > CC=/opt/ibmcmp/vac/7.0/bin/xlc ./configure > ..A.. > checking for int timezone... yes > checking types of arguments for accept()... configure: error: > could not determine argument types The odds are very high, that it rather depends on the system header file version, or the order of inclusion (e.g. stdio.h before config.h). Would need to see the snippet of configure output though. IIRC there was a fix for this or a similar case, has this been reverted ? Andreas ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] compiling postgres with Visual Age compiler on
On P, 2005-05-29 at 11:26 -0400, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > I have not researched any deeper,but currently it fails with
>
> > checking types of arguments for accept()... configure: error: could not
> > determine argument types
>
> So look at config.log and see what's going on.
the following is repeated several times:
--8<8<8<8<8<8<8<8<--
configure:11574: /opt/ibmcmp/vac/7.0/bin/xlc -c -O -D_GNU_SOURCE conftest.c >&5
"configure", line 11556.21: 1506-166 (S) Definition of function PASCAL
requires parentheses.
"configure", line 11556.28: 1506-276 (S) Syntax error: possible missing
'{'?
configure:11577: $? = 1
configure: failed program was:
#line 11549 "configure"
#include "confdefs.h"
#ifdef HAVE_SYS_TYPES_H
#include
#endif
#ifdef HAVE_SYS_SOCKET_H
#include
#endif
extern unsigned int PASCAL accept (unsigned int, void *, unsigned int
*);
#ifdef F77_DUMMY_MAIN
# ifdef __cplusplus
extern "C"
# endif
int F77_DUMMY_MAIN() { return 1; }
#endif
int
main ()
{
;
return 0;
}
--8<8<8<8<8<8<8<8<--
and then end looks like this
--8<8<8<8<8<8<8<8<--
#define HAVE_STRUCT_SOCKADDR_STORAGE_SS_FAMILY 1
#define HAVE_STRUCT_ADDRINFO 1
#define HAVE_STRUCT_OPTION 1
#define HAVE_INT_TIMEZONE
configure: exit 1
--8<8<8<---8<8<-8<---8<-8<--
--
Hannu Krosing <[EMAIL PROTECTED]>
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Escape handling in COPY, strings, psql
Bruce Momjian wrote: > I was suggesting ESCAPE 'string' or ESC 'string'. The marker has to > be before the string so scan.l can alter its processing of the string > --- after the string is too late --- there is no way to undo any > escaping that has happened, and it might already be used by gram.y. That pretty much corresponds to my E'string' proposal. Both are probably equally trivial to implement. > I agree with Tom that COPY has to be left unchanged. The fundamental > problem is the representation of NULL values, that I don't think we > can do without some escape mechanism. Single-quote escapes works by > doubling them, but once you need to represent something more like > null's, I can't think of a solution without escapes. Yes, I now realize that COPY has a whole set of different rules anyway, so we can leave that out of this discussion. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] compiling postgres with Visual Age compiler on
On E, 2005-05-30 at 12:21 +0300, Hannu Krosing wrote: > On P, 2005-05-29 at 11:26 -0400, Tom Lane wrote: > > Hannu Krosing <[EMAIL PROTECTED]> writes: > > > I have not researched any deeper,but currently it fails with > > > > > checking types of arguments for accept()... configure: error: could not > > > determine argument types > > > > So look at config.log and see what's going on. > it needs this: extern int accept (int __fd, __SOCKADDR_ARG __addr, socklen_t *__restrict __addr_len); how does one add yet another set of arguments for accept() to configure ? -- Hannu Krosing <[EMAIL PROTECTED]> ---(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: [HACKERS] compiling postgres with Visual Age compiler on
Hannu Krosing wrote: > it needs this: > > extern int accept (int __fd, __SOCKADDR_ARG __addr, >socklen_t *__restrict __addr_len); > > how does one add yet another set of arguments for accept() to > configure ? One patches the file config/ac_func_accept_argtypes.m4. Presumably, you need to add another choice to the loop for ac_cv_func_accept_arg2. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] locks in CREATE TRIGGER, ADD FK
On 2005-05-30, Neil Conway <[EMAIL PROTECTED]> wrote: > On Wed, 2005-03-23 at 10:04 -0500, Tom Lane wrote: >> I think last night's discussion makes it crystal-clear why I felt that >> this hasn't been sufficiently thought through. Please revert until the >> discussion comes to a conclusion. > > Are there any remaining objections to reapplying this patch? I've run into a few questions recently that might be relevent to the issue of DDL locking in general and therefore possibly this change in particular. The most significant one is to do with the pg_get_*def functions and their consistency, or otherwise, with explicit scans of the system catalogs. The problem here of course is that the pg_get_*def functions mostly (but not exclusively) use the syscache and therefore see data relative to SnapshotNow, whereas the queries that are invoking them are likely to be doing explicit scans of the catalog tables within the transaction's active snapshot (and for a long-running serializable transaction such as pg_dump, these may be some way apart). The obvious place to look for failure modes is to see whether pg_dump can be made to fail by deleting something (index, perhaps?) that it is expecting to find, and see whether it chokes (pg_get_indexdef will elog if the index doesn't exist in SnapshotNow). Dropping a view might be another case where this can be made to fail. -- Andrew, Supernews http://www.supernews.com - individual and corporate NNTP services ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] Interval->day proposal
There has been discussion in the past of including number of days as part of the Interval structure in addition to the current months and time components. Here are some mailing list threads where the topic has arisen. [Re: [GENERAL] '1 year' = '360 days' ](http:// archives.postgresql.org/pgsql-general/2004-10/msg01104.php) [Re: [HACKERS] timestamp with time zone a la sql99](http:// archives.postgresql.org/pgsql-hackers/2004-10/msg00843.php) One advantage of this is that it would allow '1 day' to have a different meaning that '24 hours', which would be meaningful when crossing daylight saving time changes. For example, PostgreSQL returns the following results: test=# set time zone 'CST7CDT'; SET test=# select '2005-04-01 12:00-07'::timestamptz + '1 day'::interval; ?column? 2005-04-02 12:00:00-07 (1 row) test=# select '2005-04-02 12:00-07'::timestamptz + '1 day'::interval; ?column? 2005-04-03 13:00:00-06 (1 row) A daylight saving time change occurred at 2005-04-03 02:00. Internally, the '1 day' interval is converted to 24 hours, which is then added to '2005-04-02 12:00-07', returning '2005-04-03 13:00-06'. Distinguishing between '1 day' and '24 hours' would allow '2005-04-02 12:00-07'::timestamptz + '1 day'::interval to return '2005-04-03 12:00-06', while '2005-04-02 12:00-07'::timestamptz + '1 day'::interval would return '2005-04-03 13:00-06' as it does now. I'm interested in implementing at least part of this. In my mind there are two steps: the first is to modify the Interval data type implementation to include days as well as months and time; the second is to modify the functions used to add interval to timestamptz to take into account the difference between '1 day' and '24 hours' when working across daylight saving time changes. I'm thinking of it in two steps primarily because this is my first venture into the backend code and I'm breaking it into pieces that I hopefully deal with. Arguably, implementing only the first step isn't useful in and of itself, but I have to start somewhere, and that seems like the logical place to start. I've been looking at the current interval implementation, and am beginning to form a plan for my first cut at the code. Before starting out, I'd appreciate any feedback on my understanding of the code or my plan. In interval_in, (backend/utils/adt/timestamp.c) strings representing intervals are parsed using DecodeInterval() which is defined in backend/utils/adt/datetime.c. DecodeInterval() assigns values to the appropriate components of a pg_tm structure, which includes tm_year, tm_mon, tm_mday, tm_hour, tm_min, and tm_sec. This pg_tm data is passed to tm2interval, where the tm_year and tm_mon components are used to determine the interval->month value, and the tm_mday, tm_hour, tm_min, and tm_sec values are used to determine the interval- >time value. When the string is read by DecodeInterval, the "days" component is assigned to tm_mday. It seems relatively straightforward to use this input to provide the interval->day value. However, I'm wondering what range of days this the interval->day component can be expected to handle. tm_mday is an int value, which is only guaranteed to be 2 bytes (though it may be larger), if I understand correctly. This means that tm_mday isn't able to hold the full span of days, which is nearly 2.15 billion over the range of valid timestamps (from BC 4713 to AD 5,874,897). However, this range of days may not be necessary in practice. The (minimum) 2 bytes guaranteed by int is enough to hold +/- 44 years of days. Is it likely that DST issues are going to be important over anything larger? I'm not sure, and I welcome others' thoughts on this. If a wider range of days is deemed required, I'm not sure how this would be accomplished outside of changing the pg_tm datatype. If interval->day can be stored in an int16, then the interval struct would be widened from 12 to 14 bytes. Are there concerns about widening the interval datatype? This is perhaps a naive approach, so if anyone has other ideas, I'd love to hear them. Is my understanding correct? Any corrections or pointers appreciated. Michael Glaesemann grzm myrealbox com ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Escape handling in COPY, strings, psql
Christopher Kings-Lynne wrote: > > I think we can tell people in 8.1 that they should modify their > > applications to only use '', and that \' might be a security problem in > > the future. If we get to that then using ESC or not only affects input > > of values and literal backslashes being entered, and my guess is that > > 90% of the backslash entries that want escaping are literal in the > > application and not supplied by program variables. In fact, if we > > disable backslash by default then strings coming in only have to deal > > with single quotes (like other databases) and the system is more secure > > because there is no special backslash handling by default. > > I can tell you right now this will be a problem :) There are loads of > PHP ppl who use addslashes() instead of pg_escape_string() to escape data. I read the PHP addslashes() manual page: http://us3.php.net/addslashes First, I see what people mean about PHP having most of the complex content in comments, rather than in the actual manual text, and this tendency is certainly something we want to avoid --- you end up having to digest all the comments to find the details that should be in the manual already. On to the case at hand, the comments mention that addslashes() isn't safe for all databases, and in fact isn't the prefered method. I do think it could be a problem we have to have people avoid. One idea for 8.1 is to throw a warning if \' appears in a string, thereby helping people find the places they are using the incorrect non-standard escaping. -- 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 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Escape handling in COPY, strings, psql
I read the PHP addslashes() manual page: http://us3.php.net/addslashes First, I see what people mean about PHP having most of the complex content in comments, rather than in the actual manual text, and this tendency is certainly something we want to avoid --- you end up having to digest all the comments to find the details that should be in the manual already. Actually, all the comments are posted on the php-doc list, with automatic urls in them for 'fixed in cvs', 'rejected', etc. Each comment is supposed to be acted upon (ie. fixed in source), then deleted. There's still a lot of old comment around that hasn't had that treatment though... Chris ---(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: [HACKERS] Escape handling in COPY, strings, psql
Christopher Kings-Lynne wrote: > > I read the PHP addslashes() manual page: > > > > http://us3.php.net/addslashes > > > > First, I see what people mean about PHP having most of the complex > > content in comments, rather than in the actual manual text, and this > > tendency is certainly something we want to avoid --- you end up having > > to digest all the comments to find the details that should be in the > > manual already. > > Actually, all the comments are posted on the php-doc list, with > automatic urls in them for 'fixed in cvs', 'rejected', etc. > > Each comment is supposed to be acted upon (ie. fixed in source), then > deleted. > > There's still a lot of old comment around that hasn't had that treatment > though... Right, they are more _usage_ comments, but still I think they could be consolidated into manual text. -- 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Escape handling in COPY, strings, psql
Peter Eisentraut wrote: > Bruce Momjian wrote: > > I was suggesting ESCAPE 'string' or ESC 'string'. The marker has to > > be before the string so scan.l can alter its processing of the string > > --- after the string is too late --- there is no way to undo any > > escaping that has happened, and it might already be used by gram.y. > > That pretty much corresponds to my E'string' proposal. Both are > probably equally trivial to implement. Right. I think your E'' idea has the benefit of fitting with our existing X'' and B'' modifiers. It is also simpler and cleaner to do in scan.l, so I think your idea is best. > > I agree with Tom that COPY has to be left unchanged. The fundamental > > problem is the representation of NULL values, that I don't think we > > can do without some escape mechanism. Single-quote escapes works by > > doubling them, but once you need to represent something more like > > null's, I can't think of a solution without escapes. > > Yes, I now realize that COPY has a whole set of different rules anyway, > so we can leave that out of this discussion. Cool. -- 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Escape handling in COPY, strings, psql
Bruce Momjian writes: > Christopher Kings-Lynne wrote: > > > > Each comment is supposed to be acted upon (ie. fixed in source), then > > deleted. > > Right, they are more _usage_ comments, but still I think they could be > consolidated into manual text. If that's "supposed" to happen it certainly hasn't been the de facto procedure. I think they have things partly right here though. A lot of those comments aren't actually the kinds of things that belong in the canonical reference. They include things like "watch out for this common error" or "here's a handy use for this function". Often the "common error" or "handy use" are pretty bogus but every now and then there's a genuinely useful one. These kinds of things would just clutter up a reference. A reference should just state unambiguously this function does XYZ and give examples that help explain XYZ. The PHP Docs do have a bit of a problem in that often the comments include things like "In case X, what happens is Y" which really ought to be covered by the canonical reference. That's a problem. -- greg ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Interval->day proposal
Michael Glaesemann <[EMAIL PROTECTED]> writes: > When the string is read by DecodeInterval, the "days" component is > assigned to tm_mday. It seems relatively straightforward to use this > input to provide the interval->day value. However, I'm wondering what > range of days this the interval->day component can be expected to > handle. tm_mday is an int value, which is only guaranteed to be 2 > bytes (though it may be larger), if I understand correctly. Actually, practically all of the Postgres code assumes int is at least 32 bits. Feel free to change pg_tm's field to be declared int32 instead of just int if that bothers you, but it is really quite academic. > If interval->day can be stored in an int16, then the interval struct > would be widened from 12 to 14 bytes. Are there concerns about > widening the interval datatype? I'd make the on-disk field an int32, taking the struct to 16 bytes. Given that it already requires double alignment for the embedded double-or-int8 field, it's likely that it effectively takes 16 bytes anyway after you count padding effects. So I don't see any percentage in trying to shave a couple bytes. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Interval->day proposal
Michael, > One advantage of this is that it would allow '1 day' to have a > different meaning that '24 hours', which would be meaningful when > crossing daylight saving time changes. For example, PostgreSQL > returns the following results: I've been stumping for this for years. See my arguments with Thomas Lockhart in 2000. A "calendar day" is not the same as 24 hours, and DST behavior has forced me to use TIMESTAMP WITHOUT TIME ZONE on many a calendaring application. Unfortunately, it appears that tri-partitioning INTERVAL ( year/month ; week/day ; hour/minute/second ) is a violation of the SQL spec which has only the two partitions ( year/month ; week/day/hour/minute/second ). Have they changed this in SQL 2003?If not, do we want to do it anyway, perhaps using a 2nd interval type? -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Interval->day proposal
Josh Berkus writes: > Unfortunately, it appears that tri-partitioning INTERVAL ( year/month ; > week/day ; hour/minute/second ) is a violation of the SQL spec which has only > the two partitions ( year/month ; week/day/hour/minute/second ). I think it's an extension of the spec, not a violation. In particular, if you were working in a daylight-savings-less timezone, you could not tell the difference (could you?) The spec's worldview essentially corresponds to daylight-savings-less all the time, and so they are already a subset of what we do. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] US Goverment and Patents
FYI, two weeks ago I attended the Computer & Communications Industry Association (http://www.ccianet.org/) 2005 Summit in Washington. I was invited as a member of an open source project. It was a great opportunity for our project to get visibility in Washington among industry lobbyist and government officials. The caucus covered a few major areas: computer security, identity theft, patent reform, and homeland security. One good piece of news is that the US patent problems are clearly recognized by the government and new legislation is being worked on to try to fix some of the existing software patent problems. That legislation might be passed this year. The goal is to try to prevent trivial patents and to make patent challenges easier/cheaper. One issue I expressed there is how vulnerable open source is to patent attacks because we don't have money to defend even trivial challenges. Here are a few PDF's written by the CCIA that I think addresses many of the patent issues very clearly: Open Source and Software Patents: http://candle.pha.pa.us/ccia/Patent_Abstract.pdf Software Patents: http://candle.pha.pa.us/ccia/CCIA_Patent_Policy_2-pager.pdf Detailed Patent Analysis: http://candle.pha.pa.us/ccia/innovationrpt.pdf Fairly Considering Open Source for Government Contracts: http://candle.pha.pa.us/ccia/procurement2.pdf I know some people were looking for a patent statement to put on our web site. The first PDF would be an excellent choice. -- 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 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] Fix for cross compilation
In 8.0, PostgreSQL lost its previously postulated ability to be cross-compiled and it turns out some people actually used that, so here's an attempt to fix it. The problem is that the program zic in src/timezone/ is built and run during the build process, which doesn't work if it's compiled by a cross-compiler. The standard way to go about this in autotools land (references: gcc, binutils) is to introduce a second variable CC_FOR_BUILD that is set to a native compiler. There is no particular way to determine this variable; it's passed by the user or defaults to $CC. This variable is then used in place of CC to build programs that are compiled and run during the build. The problem is that native compilations cannot rely on things that the build system normally provides because the tests are run for the target system, not the build system. It can be assumed that the compilers are of the same kind, so using CFLAGS etc. is OK. But one cannot rely on libraries for example without entering a world of pain. Since most programs that need native compilation are usually some small conversion programs, this generally works out well anyway. Attached is a patch that implements that principle for zic. zic can no longer use libpgport, but the only thing it seems to use from there is strerror() and I like to think that we can get away with that. I haven't actually tried this out with a cross compilation since I'm not set up for it, so if someone has an environment available, please give this a try. Comments? -- Peter Eisentraut http://developer.postgresql.org/~petere/ diff -cr -x configure ../cvs-pgsql/configure.in ./configure.in *** ../cvs-pgsql/configure.in 2005-05-30 17:34:59.0 +0200 --- ./configure.in 2005-05-30 18:35:15.212677930 +0200 *** *** 304,309 --- 304,320 # + # Native compiler + # + + if test -z "$CC_FOR_BUILD"; then + CC_FOR_BUILD=$CC + fi + + AC_SUBST(CC_FOR_BUILD) + + + # # Set up TAS assembly code if needed; the template file has now had its # chance to request this. # diff -cr -x configure ../cvs-pgsql/src/Makefile.global.in ./src/Makefile.global.in *** ../cvs-pgsql/src/Makefile.global.in 2005-05-30 17:35:05.0 +0200 --- ./src/Makefile.global.in 2005-05-30 18:39:39.750672139 +0200 *** *** 182,187 --- 182,188 endif # not PGXS CC = @CC@ + CC_FOR_BUILD = @CC_FOR_BUILD@ GCC = @GCC@ CFLAGS = @CFLAGS@ diff -cr -x configure ../cvs-pgsql/src/timezone/Makefile ./src/timezone/Makefile *** ../cvs-pgsql/src/timezone/Makefile 2005-01-04 20:41:01.0 +0100 --- ./src/timezone/Makefile 2005-05-30 19:11:46.708533716 +0200 *** *** 18,24 OBJS= localtime.o strftime.o pgtz.o # files needed to build zic utility program ! ZICOBJS= zic.o ialloc.o scheck.o localtime.o # timezone data files TZDATA := africa antarctica asia australasia europe northamerica southamerica \ --- 18,24 OBJS= localtime.o strftime.o pgtz.o # files needed to build zic utility program ! ZICOBJS= zic.o ialloc.o scheck.o localtime-zic.o # timezone data files TZDATA := africa antarctica asia australasia europe northamerica southamerica \ *** *** 30,37 SUBSYS.o: $(OBJS) $(LD) $(LDREL) $(LDOUT) SUBSYS.o $(OBJS) zic: $(ZICOBJS) ! $(CC) $(CFLAGS) $(ZICOBJS) $(LDFLAGS) $(LIBS) -o [EMAIL PROTECTED](X) install: all installdirs ./zic -d $(DESTDIR)$(datadir)/timezone $(TZDATAFILES) --- 30,46 SUBSYS.o: $(OBJS) $(LD) $(LDREL) $(LDOUT) SUBSYS.o $(OBJS) + # In case of cross-compilation, zic needs to be built with a native + # compiler because it is run during the build, not on the final + # system. + + localtime-zic.c: localtime.c + $(LN_S) $< $@ + + $(ZICOBJS): CC=$(CC_FOR_BUILD) + zic: $(ZICOBJS) ! $(CC_FOR_BUILD) $(CFLAGS) $(ZICOBJS) -o [EMAIL PROTECTED](X) install: all installdirs ./zic -d $(DESTDIR)$(datadir)/timezone $(TZDATAFILES) *** *** 40,43 $(mkinstalldirs) $(DESTDIR)$(datadir) clean distclean maintainer-clean: ! rm -f SUBSYS.o zic$(X) $(OBJS) $(ZICOBJS) --- 49,52 $(mkinstalldirs) $(DESTDIR)$(datadir) clean distclean maintainer-clean: ! rm -f SUBSYS.o zic zic$(X) $(OBJS) $(ZICOBJS) localtime-zic.c ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] Autoconf update?
Does anyone object if we moved to Autoconf 2.59? It's been the last release for 18 months now, so it seems reasonable to settle on it. I'm not actually looking to use features from there, but it gets a bit annoying to have to keep so many Autoconf versions around. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Fix for cross compilation
What about our threading configure test? That doesn't allow cross compilation either, does it? --- Peter Eisentraut wrote: > In 8.0, PostgreSQL lost its previously postulated ability to be > cross-compiled and it turns out some people actually used that, so > here's an attempt to fix it. > > The problem is that the program zic in src/timezone/ is built and run > during the build process, which doesn't work if it's compiled by a > cross-compiler. > > The standard way to go about this in autotools land (references: gcc, > binutils) is to introduce a second variable CC_FOR_BUILD that is set to > a native compiler. There is no particular way to determine this > variable; it's passed by the user or defaults to $CC. This variable is > then used in place of CC to build programs that are compiled and run > during the build. > > The problem is that native compilations cannot rely on things that the > build system normally provides because the tests are run for the target > system, not the build system. It can be assumed that the compilers are > of the same kind, so using CFLAGS etc. is OK. But one cannot rely on > libraries for example without entering a world of pain. Since most > programs that need native compilation are usually some small conversion > programs, this generally works out well anyway. > > Attached is a patch that implements that principle for zic. zic can no > longer use libpgport, but the only thing it seems to use from there is > strerror() and I like to think that we can get away with that. > > I haven't actually tried this out with a cross compilation since I'm not > set up for it, so if someone has an environment available, please give > this a try. > > Comments? > > -- > Peter Eisentraut > http://developer.postgresql.org/~petere/ [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 8: explain analyze is your friend -- 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: [HACKERS] Fix for cross compilation
Peter Eisentraut <[EMAIL PROTECTED]> writes: > The problem is that the program zic in src/timezone/ is built and run > during the build process, which doesn't work if it's compiled by a > cross-compiler. Why don't we instead arrange to run it during install? I'm not real thrilled with the notion of trying to use a zic built by a different compiler; I think that will lead to all sorts of problems, considering that the files it's meant to write are binary and at least potentially architecture-specific. Also there's the problem that it is reading a pg_config.h that is definitely platform-specific. BTW, the truth of the matter is that we've never supported cross-compilation; see all the AC_TRY_RUN operations in configure. 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: [HACKERS] Autoconf update?
Peter Eisentraut <[EMAIL PROTECTED]> writes: > Does anyone object if we moved to Autoconf 2.59? It's been the last > release for 18 months now, so it seems reasonable to settle on it. I'm > not actually looking to use features from there, but it gets a bit > annoying to have to keep so many Autoconf versions around. Well, it'll still be necessary to keep 2.53 around, unless you want to move to 2.59 for future releases of the back branches too ... which might be OK, I'm not sure. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Backslash handling in strings
Bruce Momjian wrote: > Peter Eisentraut wrote: > > Bruce Momjian wrote: > > > I was suggesting ESCAPE 'string' or ESC 'string'. The marker has to > > > be before the string so scan.l can alter its processing of the string > > > --- after the string is too late --- there is no way to undo any > > > escaping that has happened, and it might already be used by gram.y. > > > > That pretty much corresponds to my E'string' proposal. Both are > > probably equally trivial to implement. > > Right. I think your E'' idea has the benefit of fitting with our > existing X'' and B'' modifiers. It is also simpler and cleaner to do in > scan.l, so I think your idea is best. [ CC list trimmed.] OK, I talked to Tom and Peter and I have come up with a tentative plan. The goal, at some point, is that we would have two types of strings, '' strings and E'' strings. '' strings don't have any special backslash handling for compatibility with with the ANSI spec and all other databases except MySQL (and in MySQL it is now optional). E'' strings behave just like our strings do now, with backslash handling. In 8.0.X, we add support for E'' strings, but it is a noop. This is done just for portability with future releases. We also state that users should stop using \' to escape quotes in strings, and instead use '', and that we will throw a warning in 8.1 if we see a \' in a non-E string. (We could probably throw a warning for E'' use of \' too, but I want to give users the ability to avoid the warning if they can't change from using \' to ''.) In 8.1, we start issuing the warning for \' in non-E strings, plus we tell users who want escape processing that they will have to use E'' strings for this starting in release 8.2, and they should start migrating their escaped strings over to E''. Tom also suggested a readonly GUC variable that is sent to clients that indicates if simple strings have backslash handling, for use by applications that are doing escapes themselves, perhaps 'escape_all_strings'. PQescapeString() and PQescapeBytea() can still be used, but only with E'' strings in 8.2. We could create PQquoteString() for 8.1 and later to allow for just single-quote doubling for non-E strings. Tom asked about how to handle pg_dump contents that have strings, like function bodies. We could start using E'' for those in 8.0 but it does break backward movement of dumps, and someone upgrading from 7.1 to 8.2 would be in trouble. :-( Perhaps we will have another round of subrelease fixes and we can bundle this into that and tell people they have to upgrade to the newest subrelease before going to 8.2. I think we have had that requirement in the past when we had broken pg_dump processing. The good news is that once everyone uses only '' to quote string, we will not have any data security issues with this change. The only potential problem is the mishandling of backslash characters if there is a mismatch between what the client expects and the server uses. By backpatching E'' perhaps even to 7.4 and earlier (as a noop), we could minimize this problem. Is this whole thing ugly? Yes. Can we just close our eyes and hope we can continue with our current behavior while growing a larger userbase --- probabably not. -- 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [PATCHES] Adding \x escape processing to COPY, psql, backend
Tom Lane wrote: > Bruce Momjian writes: > > Here is a new version of the three \x hex support patches. I have added > > \x for psql variables, which is the last patch. > > > I have IM'ed with Peter and he is now OK with the idea of supporting \x, > > with the underestanding that it doesn't take us any farther away from > > compatibility than we are now. > > Peter may be OK with it, but I object strongly to adding this to SQL > literals. This is exactly *not* the direction we want to be going in. > > I don't really see the point for COPY and psql, either. We already support \n, \r, \t, and \octal. I don't see any problem with improving it. It does not take us any closer or farther away from spec compliance. COPY \x has been requested by several people, and there are actually two patches that have been submitted in the past year for this. As you know, escapes already provide a useful mechanism on COPY and SQL strings, and there is a plan I just posted to deal with standards issues, but I don't see \x taking us closer or farther from this. Please explain why this takes us in the wrong direction. -- 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] [HACKERS] Inherited constraints and search paths (was
Added to TODO: * Prevent child tables from altering constraints like CHECK that were inherited from the parent table --- Tom Lane wrote: > Simon Riggs <[EMAIL PROTECTED]> writes: > > Doing anything to restrict dropping of inherited constraints seems like > > wasted effort and potentially annoying anyhow. > > Uh, why? Arguably the constraints are as much part of the parent table > definition as the columns themselves. If you had "check (f1 > 0)" in > the definition of a table, wouldn't you be pretty surprised to select > from it and find rows with f1 < 0? > > regression=# create table parent(f1 int check (f1 > 0)); > CREATE TABLE > regression=# create table child() inherits(parent); > CREATE TABLE > regression=# alter table child drop constraint parent_f1_check; > ALTER TABLE > regression=# insert into child values(-1); > INSERT 0 1 > regression=# select * from parent; > f1 > > -1 > (1 row) > > I think a good argument can be made that the above behavior is a bug, > and that the ALTER command should have been rejected. We've gone to > great lengths to make sure you can't ALTER a child table to make it > incompatible with the parent in terms of the column names and types; > shouldn't this be true of check constraints as well? > > 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 > -- 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] pg_buffercache causes assertion failure
Mark Kirkwood wrote: I couldn't use int4 as the underlying datatype is unsigned int (not available as exposed Pg type). However, using int8 sounds promising (is int8 larger than unsigned int on 64-bit platforms?). Blocknumber is defined as uint32 in block.h - so should always be safe to represent as an int8 I am thinking. I will look at patching pg_buffercache, changing numeric -> int8 for the relblocknumber column. This seems a tidier solution than using numeric, and loses the numeric overhead. regards Mark ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] pg_buffercache causes assertion failure
Mark Kirkwood wrote: Mark Kirkwood wrote: I couldn't use int4 as the underlying datatype is unsigned int (not available as exposed Pg type). However, using int8 sounds promising (is int8 larger than unsigned int on 64-bit platforms?). Blocknumber is defined as uint32 in block.h - so should always be safe to represent as an int8 I am thinking. I will look at patching pg_buffercache, changing numeric -> int8 for the relblocknumber column. This seems a tidier solution than using numeric, and loses the numeric overhead. This patch changes the use of numeric to int8 to represent the relblocknumber column. regards Mark diff -Ncar pgsql.orig/contrib/pg_buffercache/README.pg_buffercache pgsql/contrib/pg_buffercache/README.pg_buffercache *** pgsql.orig/contrib/pg_buffercache/README.pg_buffercache Tue May 31 11:02:41 2005 --- pgsql/contrib/pg_buffercache/README.pg_buffercache Tue May 31 11:05:48 2005 *** *** 66,78 relfilenode| oid | reltablespace | oid | reldatabase| oid | !relblocknumber | numeric | isdirty| boolean | View definition: SELECT p.bufferid, p.relfilenode, p.reltablespace, p.reldatabase, p.relblocknumber, p.isdirty FROM pg_buffercache_pages() p(bufferid integer, relfilenode oid, ! reltablespace oid, reldatabase oid, relblocknumber numeric(10,0), isdirty boolean); regression=# SELECT c.relname, count(*) AS buffers --- 66,78 relfilenode| oid | reltablespace | oid | reldatabase| oid | !relblocknumber | bigint | isdirty| boolean | View definition: SELECT p.bufferid, p.relfilenode, p.reltablespace, p.reldatabase, p.relblocknumber, p.isdirty FROM pg_buffercache_pages() p(bufferid integer, relfilenode oid, ! reltablespace oid, reldatabase oid, relblocknumber bigint, isdirty boolean); regression=# SELECT c.relname, count(*) AS buffers diff -Ncar pgsql.orig/contrib/pg_buffercache/pg_buffercache.sql.in pgsql/contrib/pg_buffercache/pg_buffercache.sql.in *** pgsql.orig/contrib/pg_buffercache/pg_buffercache.sql.in Tue May 31 11:02:41 2005 --- pgsql/contrib/pg_buffercache/pg_buffercache.sql.in Tue May 31 09:15:03 2005 *** *** 11,17 CREATE VIEW pg_buffercache AS SELECT P.* FROM pg_buffercache_pages() AS P (bufferid integer, relfilenode oid, reltablespace oid, reldatabase oid, !relblocknumber numeric(10), isdirty bool); -- Don't want these to be available at public. REVOKE ALL ON FUNCTION pg_buffercache_pages() FROM PUBLIC; --- 11,17 CREATE VIEW pg_buffercache AS SELECT P.* FROM pg_buffercache_pages() AS P (bufferid integer, relfilenode oid, reltablespace oid, reldatabase oid, !relblocknumber int8, isdirty bool); -- Don't want these to be available at public. REVOKE ALL ON FUNCTION pg_buffercache_pages() FROM PUBLIC; diff -Ncar pgsql.orig/contrib/pg_buffercache/pg_buffercache_pages.c pgsql/contrib/pg_buffercache/pg_buffercache_pages.c *** pgsql.orig/contrib/pg_buffercache/pg_buffercache_pages.cTue May 31 11:02:41 2005 --- pgsql/contrib/pg_buffercache/pg_buffercache_pages.c Tue May 31 11:23:46 2005 *** *** 93,99 TupleDescInitEntry(tupledesc, (AttrNumber) 4, "reldatabase", OIDOID, -1, 0); TupleDescInitEntry(tupledesc, (AttrNumber) 5, "relblockbumber", ! NUMERICOID, -1, 0); TupleDescInitEntry(tupledesc, (AttrNumber) 6, "isdirty", BOOLOID, -1, 0); --- 93,99 TupleDescInitEntry(tupledesc, (AttrNumber) 4, "reldatabase", OIDOID, -1, 0); TupleDescInitEntry(tupledesc, (AttrNumber) 5, "relblockbumber", ! INT8OID, -1, 0); TupleDescInitEntry(tupledesc, (AttrNumber) 6, "isdirty", BOOLOID, -1, 0); ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] A 2 phase commit weirdness
On Fri, May 27, 2005 at 11:12:06AM -0400, Tom Lane wrote: > Heikki Linnakangas <[EMAIL PROTECTED]> writes: > > Looking at the sequence, at least the relcache init file stuff looks if > > not broken at least a bit heavy-handed... > > I was planning to change that ;-) ... using separate 2PC action records > for the relcache init file actions would make it much better. Hum, do you mean separate for 2PC only, or make'em completely separate invalidation messages? I fixed the problem I had -- it was very easy to make the messages get processed locally. However strangeness can still happen. Consider: create table foo (); begin; drop table foo; prepare transaction 'foo'; Now any backend that tries to access table foo will block, because the 'foo' prepared transaction has acquired a lock on it. However the table is still visible in the catalogs, as it should be. It can easily be awakened by other backend doing commit transaction 'foo'; But at awakening, the user will get this: ERROR: relation 66002 deleted while still in use This is ugly -- I don't think there is a way to get out of it. Unrelated question: is it intended that the prepared transactions are visible cross-database through pg_prepared_xacts? -- Alvaro Herrera () "No single strategy is always right (Unless the boss says so)" (Larry Wall) ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Autoconf update?
Well, it'll still be necessary to keep 2.53 around, unless you want to move to 2.59 for future releases of the back branches too ... which might be OK, I'm not sure. I thought it was to help the public not have to keep so many versions around :) Chris ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] Consumer-grade vs enterprise-grade disk drives
I'm not sure whether this article has been mentioned here before, but it definitely is worth a read: http://www.usenix.org/events/fast03/tech/full_papers/anderson/anderson_html/ >From the proceedings of the FAST '03 conference: More than an interface - SCSI vs. ATA Dave Anderson, Jim Dykes, Erik Riedel Seagate Research Abstract: This paper sets out to clear up a misconception prominent in the storage community today, that SCSI disc drives and IDE (ATA) disc drives are the same technology internally, and differ only in their external interface and in their suggested retail price. ... This paper attempts to clarify the differences by illuminating some of these design choices and their consequences on final device characteristics. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Backslash handling in strings
Bruce Momjian writes: > The goal, at some point, is that we would have two types of strings, '' > strings and E'' strings. '' strings don't have any special backslash > handling for compatibility with with the ANSI spec and all other > databases except MySQL (and in MySQL it is now optional). E'' strings > behave just like our strings do now, with backslash handling. The only thing I'm not clear on is what exactly is the use case for E'' strings. That is, who do you expect to actually use them? Any new applications are recommended to be using '' strings. And any existing applications obviously won't be using them since they don't currently exist. The only potential candidates are existing applications being ported forward. And that only makes sense if they're currently using some function like addslash. Is it really easier to change all the SQL queries to use E'' (and still have a bug) than it is to replace addslash with PQquoteString() ? Also, I'm really confused why you would make PQescapeString require E'' strings and introduce a new function. That means existing non-buggy applications would suddenly be buggy? And it would be impossible to write a properly functioning application that interpolates a constant into a query that would be portable to 8.2 and 8.0? -- greg ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Backslash handling in strings
Greg Stark wrote: > Bruce Momjian writes: > > > The goal, at some point, is that we would have two types of strings, '' > > strings and E'' strings. '' strings don't have any special backslash > > handling for compatibility with with the ANSI spec and all other > > databases except MySQL (and in MySQL it is now optional). E'' strings > > behave just like our strings do now, with backslash handling. > > > The only thing I'm not clear on is what exactly is the use case for E'' > strings. That is, who do you expect to actually use them? > > Any new applications are recommended to be using '' strings. And any existing > applications obviously won't be using them since they don't currently exist. We are saying to use '' to escape single quotes in all strings. E'' is still useful if you want to use backslash escapes in your strings. Does that answer your questions? -- 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Consumer-grade vs enterprise-grade disk drives
Yea, it is a great paper. It is an HTML version of the SCSI PDF I mentioned a few weeks ago: http://www.seagate.com/content/docs/pdf/whitepaper/D2c_More_than_Interface_ATA_vs_SCSI_042003.pdf Someone had mentioned it on the lists a few months ago but I only read it recently and resuggested it. One problem with the web version is that the images didn't transfer very clearly. I mention it in my hardware performance tuning paper. --- Tom Lane wrote: > I'm not sure whether this article has been mentioned here before, but > it definitely is worth a read: > > http://www.usenix.org/events/fast03/tech/full_papers/anderson/anderson_html/ > > >From the proceedings of the FAST '03 conference: > > More than an interface - SCSI vs. ATA Dave Anderson, Jim Dykes, > Erik Riedel Seagate Research > > Abstract: > > This paper sets out to clear up a misconception prominent in the storage > community today, that SCSI disc drives and IDE (ATA) disc drives are > the same technology internally, and differ only in their external > interface and in their suggested retail price. ... This paper attempts > to clarify the differences by illuminating some of these design choices > and their consequences on final device characteristics. > > 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Consumer-grade vs enterprise-grade disk drives
Tom, This is a story that is evolving. Anyone else use StorageReview? Great comprehensive drive benchmarks: http://www.storagereview.com/ Check the comparisons between 15K RPM SCSI drives and the 2004 Western Digital 10K RPM SATA (Raptor) drives. The Raptors are an interesting hybrid of SCSI-related tech and desktop tech, and were some of the first drives with SCSI-like command queuing TCQ/NCQ. I think the last remaining issue in moving to SATA for all enterprise use is the lack of decent SATA controllers, though 3Ware (http://www.3ware.com) is getting there: http://www.3ware.com/link/pdf/Serial-ATA.pdf http://www.3ware.com/products/benchmarks_sata.asp - Luke ---(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: [HACKERS] Consumer-grade vs enterprise-grade disk drives
Luke Lonergan wrote: Tom, This is a story that is evolving. Anyone else use StorageReview? Great comprehensive drive benchmarks: http://www.storagereview.com/ Check the comparisons between 15K RPM SCSI drives and the 2004 Western Digital 10K RPM SATA (Raptor) drives. The Raptors are an interesting hybrid of SCSI-related tech and desktop tech, and were some of the first drives with SCSI-like command queuing TCQ/NCQ. I think the last remaining issue in moving to SATA for all enterprise use is the lack of decent SATA controllers, though 3Ware (http://www.3ware.com) is getting there: http://www.3ware.com/link/pdf/Serial-ATA.pdf http://www.3ware.com/products/benchmarks_sata.asp Although the benchmark numbers are pretty good, they have only published (what looks like) results for sequential IO. It would be interesting to see the random ones, as this would tell us how effective the TCQ implementation is. Cheers Mark ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Consumer-grade vs enterprise-grade disk drives
Mark Kirkwood wrote: Luke Lonergan wrote: Although the benchmark numbers are pretty good, they have only published (what looks like) results for sequential IO. It would be interesting to see the random ones, as this would tell us how effective the TCQ implementation is. Referring to 3ware's benchmark - sorry for the confusion ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Backslash handling in strings
Greg Stark <[EMAIL PROTECTED]> writes:
> The only thing I'm not clear on is what exactly is the use case for E''
> strings. That is, who do you expect to actually use them?
The case that convinced me we need to keep some sort of backslash
capability is this: suppose you want to put a string including a tab
into your database. Try to do it with psql:
t=> insert into foo values ('
Guess what: you won't get anywhere, at least not unless you disable
readline. So it's nice to be able to use \t.
There are related issues involving \r and \n depending on your platform.
And this doesn't even scratch the surface of encoding-related funnies.
So there's definitely a use-case for keeping the existing backslash
behavior, and E'string' seems like a reasonable proposal for doing that
without conflicting with the SQL spec.
What I do not see at the moment is how we get there from here (ie,
dropping backslashing in regular literals) without incurring tremendous
pain --- including breaking all existing pg_dump files, introducing
security holes and/or data corruption into many existing apps that are
not presently broken, and probably some other ways of ruining your day.
I'm quite unconvinced that this particular letter of the SQL spec is
worth complying with ...
regards, tom lane
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] A 2 phase commit weirdness
Alvaro Herrera <[EMAIL PROTECTED]> writes: > But at awakening, the user will get this: > ERROR: relation 66002 deleted while still in use > This is ugly -- I don't think there is a way to get out of it. There had better be a way, since (I suppose) the ERROR is preventing the commit from succeeding ... > Unrelated question: is it intended that the prepared transactions are > visible cross-database through pg_prepared_xacts? That is a good question. Can a backend running in a different database execute the COMMIT (or ROLLBACK)? Offhand I'd bet that will not work, which suggests we'd better make the view per-database. [ thinks a bit more... ] We might be able to make it work, but there seems like a lot of potential for bugs/fragility there. Might be best to take the narrow definition to start with. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
