Re: [HACKERS] [GENERAL] Rollback on Error
On Fri, Oct 08, 2004 at 08:40:56PM +0200, Michael Paesold wrote: > I hope you will be willing to comment on the issues when times come. I am > not really satisfied myself, but without further discussion I did not want > to continue to work on it. Anyway, I understand this is not the right time > now (8.0 beta). I think it would be wise to create a function to discover what savepoints are available, and from that know when to release an automatically- established savepoint. Of course, the function would only work when the backend is not in abort state, but I think that's a reasonable restriction. -- Alvaro Herrera (<[EMAIL PROTECTED]>) "Ni aun el genio muy grande llegaría muy lejos si tuviera que sacarlo todo de su propio interior" (Goethe) ---(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] Does psql use nested transactions?
On Tue, Aug 17, 2004 at 03:33:01PM -0300, Haroldo Stenger wrote: Haroldo, > On Wed, 11 Aug 2004 11:47:35 -0400, Tom Lane <[EMAIL PROTECTED]> wrote: > > The other objection is that this would create very substantial overhead. > > why? Establishing a savepoint is a non-trivial operation (cost-wise). Several internal server structures have to be prepared for it. It's way cheaper than normal transaction start and commit, but undesirable anyway if done once per query. Worse if it's going to be seldom used. -- Alvaro Herrera (<[EMAIL PROTECTED]>) "La experiencia nos dice que el hombre peló millones de veces las patatas, pero era forzoso admitir la posibilidad de que en un caso entre millones, las patatas pelarían al hombre" (Ijon Tichy) ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] pg_subtrans and WAL
On Tue, Aug 10, 2004 at 12:24:06PM -0400, Tom Lane wrote: > My discovery last night of a WAL synchronization error in pg_clog led me > to take a look at pg_subtrans too. I soon realized that in fact we are > not WAL-logging pg_subtrans updates at all: subtransaction start sets up > a pg_subtrans entry but makes no WAL entry for this action. > > Seems like this is a problem. Rats :-( You are probably right. In fact this was on my todo list and I overlooked it -- it was mentioned during early discussion. Right now I am heading to Bolivia for a conference, so I am not able to do anything codewise right now, and I'll most likely have very intermitent connection ... I'll be back on monday 16. -- Alvaro Herrera (<[EMAIL PROTECTED]>) "Estoy de acuerdo contigo en que la verdad absoluta no existe... El problema es que la mentira sí existe y tu estás mintiendo" (G. Lama) ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Analyze using savepoints?
On Mon, Aug 09, 2004 at 04:44:58PM +0800, Christopher Kings-Lynne wrote: > I read this in the release notes: > > --- > # Database-wide ANALYZE does not hold locks across tables (Tom) > > This reduces the potential for deadlocks against other backends that > want exclusive locks on tables. To get the benefit of this change, do > not execute database-wide ANALYZE inside a transaction block (BEGIN > block); it must be able to commit and start a new transaction for each > table. > --- > > Does that mean that now if we used savepoints internally, analyze can > still be run in a transaction and still not hold lots of locks? No, because savepoints do not release locks on successful completion, only on rollback. I think both VACUUM and ANALYZE could be best served by appropiate use of short-lived ResourceOwners. It needs some thought though. -- Alvaro Herrera (<[EMAIL PROTECTED]>) "El realista sabe lo que quiere; el idealista quiere lo que sabe" (Anónimo) ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Proposal for Disable Triggers
On Mon, Aug 09, 2004 at 11:56:17AM +1000, fastpgs wrote: > On Sun, 8 Aug 2004 08:19, Alvaro Herrera wrote: > > > If the change is global, what should happen on other sessions that have > > a deferred event from that trigger concurrently with the one that > > modifies it? Should the answer be different depending on the isolation > > mode of the transaction? > > This was my other question It depends on how we are going to treat the > trigger already on the deferred stack... Are we going to execute the trigger > as if its status wasn't changed or are we going to double check its status > just before executing the trigger body ?? No, I'm talking about a different issue. Not what happens with a deferred event in the queue of the backend executing the disabling operation, but in another backend. Think about referential integrity triggers. Will you allow one backend, that needs to do some strange processing bypassing the triggers, make all other backends corrupt data by running with triggers disabled? It doesn't apply only to referential integrity triggers, of course. The user would need to lock the table to make sure no one uses it while she have the trigger disabled. That's no good. I think permanent or global trigger changes are recipes for disaster. -- Alvaro Herrera (<[EMAIL PROTECTED]>) La web junta la gente porque no importa que clase de mutante sexual seas, tienes millones de posibles parejas. Pon "buscar gente que tengan sexo con ciervos incendiánse", y el computador dirá "especifique el tipo de ciervo" (Jason Alexander) ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] try/catch macros for Postgres backend
On Wed, Jul 28, 2004 at 08:19:17PM -0400, Tom Lane wrote: Very cool and interesting idea. > Does anyone have a problem with this macro syntax? The try/catch names > are stolen from Java, so I'm figuring they won't terribly surprise any > modern programmer, but I'm open to different names if anyone has a > better idea. The only comment I have so far is that Java and Python appear to have settled on try/catch/finally blocks. Maybe we need three blocks too, for handling more complex scenarios. (The "finally" block, AFAIU, is executed whether an exception was raised or not, so it serves as cleanup for try and catch blocks. Somebody more knowledgeable in this OO matters may enlighten us better?) -- Alvaro Herrera (<[EMAIL PROTECTED]>) "No es bueno caminar con un hombre muerto" ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] bitwise and/or aggregate functions?
On Tue, May 18, 2004 at 12:39:08PM -0400, Neil Conway wrote: > A copy that claims to "represent an almost indistinuishable delta on the > actual SQL 2003 database standard" is available online here: > > http://www.wiscorp.com/sql/sql_2003_standard.zip Those are PDFs AFAIR, not easily greppable ... do you have a text version, or do you always look up things by looking at the TOC? I'm not thrilled with the idea of reading all 1500 pages of it ... -- Alvaro Herrera (<[EMAIL PROTECTED]>) "El día que dejes de cambiar dejarás de vivir" ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Call for 7.5 feature completion
On Mon, May 17, 2004 at 04:55:50PM +0200, Zeugswetter Andreas SB SD wrote: > > > It is too late to think about pushing back another month. We had this > > discussion already. June 1 is it. > > I thought the outcome of that discussion was June 15 ? I think there was no outcome. There was no official pronouncement, there was no vote, there was no consensus. People seemed to stick with whatever was closer. > Can we try to do the 2PC patch now instead of waiting for subtransactions ? The last post from Heikki I read said that he discovered some serious problems with his implementation and he wanted do rethink about them. I don't think he will be able to make it, mainly because if my patch gets accepted it will be too close to feature freeze (if it is June 1st). Personally I've been focused on getting subtransactions done and now I think I'm very close to an acceptable patch, but what has slowed me down the last time has been lack of feedback from core developers. It was feedback I needed to figure out the best ways to do things (I made several big mistakes that I'm only now correcting thanks to invaluable comments from Tom Lane), and without it the last steps were getting very difficult to me. Fortunately now I've got it. I have some confidence in that I will be able to deliver it maybe the last week of May. I can only hope, however, that it will not be rejected because it's presented too close to feature freeze. That would be a shame, because I offered incremental patches a lot of time ago and they weren't even looked at (Hey, I'm not blaming anyone). -- Alvaro Herrera (<[EMAIL PROTECTED]>) FOO MANE PADME HUM ---(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] Current CVS tip segfaulting
On Fri, Apr 23, 2004 at 08:38:29PM -0400, Alvaro Herrera Munoz wrote:
> On Fri, Apr 23, 2004 at 07:00:05PM -0400, Bruce Momjian wrote:
> >
> > Please recompile with debug symbols and report back the stack trace.
> > See the faq on running debug.
>
> No, I already did that (all my builds are like that anyway and I read
> stack traces more frequently than I'd like). The "can't read pathname"
> message I don't understand, but I had never seen it.
strace'ing the postmaster suggested me that the dbname string in
utils/init/postinit.c, the InitPostgres function, is the culprit.
In fact, if I apply the following patch to tcop/postgres.c the
whole thing stops happening. I don't know if this is the correct
fix, but it may suggest something. Maybe it's a problem with my
platform's argv handling (Mandrakelinux 10, kernel 2.6.3, glibc 2.3.3).
Index: postgres.c
===
RCS file: /home/alvherre/cvs/pgsql-server/src/backend/tcop/postgres.c,v
retrieving revision 1.400
diff -c -r1.400 postgres.c
*** postgres.c 19 Apr 2004 17:42:58 - 1.400
--- postgres.c 24 Apr 2004 02:20:47 -
***
*** 2686,2692
errhint("Try \"%s --help\" for more information.", argv[0])));
}
else if (argc - optind == 1)
! dbname = argv[optind];
else if ((dbname = username) == NULL)
{
ereport(FATAL,
--- 2648,2654
errhint("Try \"%s --help\" for more information.", argv[0])));
}
else if (argc - optind == 1)
! dbname = pstrdup(argv[optind]);
else if ((dbname = username) == NULL)
{
ereport(FATAL,
--
Alvaro Herrera (<[EMAIL PROTECTED]>)
"Et put se mouve" (Galileo Galilei)
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [HACKERS] Current CVS tip segfaulting
On Fri, Apr 23, 2004 at 07:00:05PM -0400, Bruce Momjian wrote: > > Please recompile with debug symbols and report back the stack trace. > See the faq on running debug. No, I already did that (all my builds are like that anyway and I read stack traces more frequently than I'd like). The "can't read pathname" message I don't understand, but I had never seen it. -- Alvaro Herrera (<[EMAIL PROTECTED]>) La web junta la gente porque no importa que clase de mutante sexual seas, tienes millones de posibles parejas. Pon "buscar gente que tengan sexo con ciervos incendiánse", y el computador dirá "especifique el tipo de ciervo" (Jason Alexander) ---(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] WITH clause
On Fri, Dec 12, 2003 at 10:13:56AM -0800, David Fetter wrote: > I'm looking to the SQL WITH clause as a way to get better regex > support in PostgreSQL. I've been chatting a little bit about this, > and here's an idea for a behavior. Implementation details TBD. I think you could be rather looking at keeping the regmatch_t * from RE_compile_and_execute somewhere in the TopTransactionContext, and create accessor functions to it. You could do BEGIN; SELECT ... x ~ '([0-9]+)x([0-9]+)'; SELECT regex_parens(1), regex_parens(2); COMMIT; Etc, you get the idea. Of course you could only access the captured expressions from the last regex, and only within the same transaction block. -- Alvaro Herrera (<[EMAIL PROTECTED]>) Maybe there's lots of data loss but the records of data loss are also lost. (Lincoln Yeoh) ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [COMMITTERS] pgsql-server/src/bin/initdb nls.mk po/it.po
On Thu, Dec 11, 2003 at 06:03:05PM -0400, Peter Eisentraut - PostgreSQL wrote: > Modified files: > src/bin/initdb : nls.mk > Added files: > src/bin/initdb/po: it.po Are you going to keep managing these things? I received your email about a CVS write account so I could handle them for you, and responded to Marc like you said, but never got anything back. (I don't quite remember if I put you as Cc: in that response.) I also wrote to -core at about the same time. -- Alvaro Herrera (<[EMAIL PROTECTED]>) "La soledad es compañía" ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [GENERAL] Transaction Question
On Thu, Dec 11, 2003 at 04:14:43PM +0100, Manfred Koizar wrote: > On Sat, 6 Dec 2003 10:43:18 -0500 (EST), Bruce Momjian > <[EMAIL PROTECTED]> wrote: > >Where are we on nested transactions. Is it something we can get for 7.5? > > I honestly don't know. I've been working on other things lately and > have not heard from Alvaro for some time. Huh, sorry for not answering. Yes, I expect to be able to deliver it in the 7.5 time frame. I will ask for help if I can't do it or if I get on problems I can't solve. -- Alvaro Herrera (<[EMAIL PROTECTED]>) "¿Que diferencia tiene para los muertos, los huérfanos, y aquellos que han perdido su hogar, si la loca destrucción ha sido realizada bajo el nombre del totalitarismo o del santo nombre de la libertad y la democracia?" (Gandhi) ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] [PERFORM] More detail on settings for pgavd?
On Fri, Nov 21, 2003 at 04:24:25PM -0500, Matthew T. O'Connor wrote: > I don't want to add tables to existing databases, as I consider that > clutter and I never like using tools that clutter my production > databases. [...] > > Actually, this might be a necessary addition as pg_autovacuum currently > suffers from the startup transients that the FSM used to suffer from, > that is, it doesn't remember anything that happened the last time it > ran. A pg_autovacuum database could also be used to store thresholds > and counts from the last time it ran. You could use the same approach the FSM uses: keep a file with the data, PGDATA/base/global/pg_fsm.cache. You don't need the data to be in a table after all ... -- Alvaro Herrera (<[EMAIL PROTECTED]>) Essentially, you're proposing Kevlar shoes as a solution for the problem that you want to walk around carrying a loaded gun aimed at your foot. (Tom Lane) ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] logical column position
On Thu, Nov 20, 2003 at 10:39:24AM -0500, Tom Lane wrote: > > (c) Do I need to consider inheritance? > > Yes. I think it'd be good if things were constrained so that columns > 1..n in a parent table always matched columns 1..n in every child, > which is not true now after adding/dropping columns. That would make it > easier/cheaper/more reliable to match up which child columns are to be > referenced in an inherited query (see adjust_inherited_attrs). No way, because of multiple inheritance. Each child should have an attparentnum, which would point to the parent's attnum for this to work ... -- Alvaro Herrera (<[EMAIL PROTECTED]>) "Aprender sin pensar es inútil; pensar sin aprender, peligroso" (Confucio) ---(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] [BUGS] Autocomplete on Postgres7.4beta5 not working?
On Tue, Oct 28, 2003 at 04:48:59PM -0500, Tom Lane wrote: > AFAICT there was no discussion about this issue when the patch was > proposed and applied. But now that the point is raised I have to say > that I don't like this change. I don't think system catalogs should be > excluded from tab completion. They never were before 7.4, and I have > not seen anyone complaining about that, other than Ian. I found it very irritating at first, but when I discovered that I could tab my way to syscatalogs by using "pg_catalog." as prefix, I started feeling it was actually a nice behavior. -- Alvaro Herrera (<[EMAIL PROTECTED]>) "Coge la flor que hoy nace alegre, ufana. ¿Quién sabe si nacera otra mañana?" ---(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] postgres --help-config
On Tue, Oct 14, 2003 at 07:52:55PM +, Jon Jensen wrote: > Is there a mailing list somewhere that all the CVS commits get sent to? Yes, pgsql-committers. > Other projects I've worked on have such a list, and each commit message is > followed by a complete diff (usually with -u for readability) so even > non-committers can do a code read right then and there while the changes > are still fresh in the author's mind and can be discussed in detail. I wouldn't want the whole diff on the mail, but a link to the relevant diffs in cvsweb would be most useful (one for each changed file -- not ideal, but much better than nothing). You're not the first one to suggest it ... -- Alvaro Herrera (<[EMAIL PROTECTED]>) "El destino baraja y nosotros jugamos" (A. Schopenhauer) ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Index/Function organized table layout
On Thu, Oct 02, 2003 at 10:09:12PM +0300, Hannu Krosing wrote: > So what you really need is the CLUSTER command to leave pages half-empty > and the tuple placement logic on inserts/updates to place new tuples > near the place where they would be placed by CLUSTER. I.e. the code that > does actual inserting should be aware of CLUSTERing. Oh, you mean like what I half-proposed in http://archives.postgresql.org/pgsql-general/2002-06/msg00968.php BTW, this is the one message (the one on the CVS log I cite at the end) that got me into Postgres hacking. The little involvement I've had has been great. Thanks to all PostgreSQL hackers! -- Alvaro Herrera (<[EMAIL PROTECTED]>) "El realista sabe lo que quiere; el idealista quiere lo que sabe" (Anonimo) ---(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 HP-UX 10.20
On Mon, Sep 15, 2003 at 04:36:10PM -0400, tachuelita wrote: > I was following an example on a book, and when I compiled it, it > finishes with the error: 1075 Function Prototypes are an ANSI feature. Huh, you need the real compiler from HP. The one bundled with the operating system is apparently not up to the task. -- Alvaro Herrera (<[EMAIL PROTECTED]>) "Cada quien es cada cual y baja las escaleras como quiere" (JMSerrat) ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [PATCHES] mcxt.c
On Tue, Sep 09, 2003 at 04:53:06PM +0200, Gaetano Mendola wrote:
> "Andrew Dunstan" <[EMAIL PROTECTED]> wrote:
> > The particular assertion that was proposed doesn't strike me as terribly
> > useful - It should be checked at the point of call rather than inside
> > pstrdup, I should have thought.
>
> Are you going to trust the client of that function ?
Yes, because it can only used in backend code and C functions, which
can be written only by a trusted user ('cause C is an untrusted language).
(I might be wrong...)
--
Alvaro Herrera (<[EMAIL PROTECTED]>)
"Use it up, wear it out, make it do, or do without"
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] tablelevel and rowlevel locks
On Thu, Sep 04, 2003 at 11:21:05AM -0700, Jenny - wrote: > >I think the locks would actually by represented by PROCLOCK structures. > >The LOCK structures are for lockable objects, not for actual locks. > > Well,from what i understand, PROCLOCK stores the TransactionID and the LOCK > its holding lock on ,so how would PROCLOCK be holding the 'actual' lock as > apposed to the lockable objects? Huh... look at http://developer.postgresql.org/pdf/internalpics.pdf pages 61 and 63. Maybe it's clearer than whatever I can say. Note that "HOLDER" has been renamed to "PROCLOCK". Anyway, I think the LOCK structure represents something that can be locked. The PROCLOCK struct represents that some process is holding a lock on said object. That may be the reason why you are seeing that a lock is held by more than one process at the same time (while in fact some of them are probably _waiting_ for the lock). -- Alvaro Herrera (<[EMAIL PROTECTED]>) "I dream about dreams about dreams", sang the nightingale under the pale moon (Sandman) ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] tablelevel and rowlevel locks
On Thu, Sep 04, 2003 at 08:56:31AM -0700, Jenny - wrote: > I am working on a project that involves displaying locking information > about each lock taken, whether it be a row level or table leve llock. > When dealing with struct LOCK (src/include/storage) i have noticed that > postgreSQL creates a single LOCK struct for each table in the db. Like if > i acquire 2 seperate row level locks on 2 seperate rows, both these locks > are represented in the same struct LOCK datastructure. I think the locks would actually by represented by PROCLOCK structures. The LOCK structures are for lockable objects, not for actual locks. -- Alvaro Herrera (<[EMAIL PROTECTED]>) "Vivir y dejar de vivir son soluciones imaginarias. La existencia está en otra parte" (Andre Breton) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] ~* operator
On Wed, Sep 03, 2003 at 01:28:16PM +0800, Christopher Kings-Lynne wrote: > Hi guys, > > Where can I find a list of all the 'special' characters in the ~* operator? They are the same for the ~ operator, and should be listed at the reference page for regular expressions... http://developer.postgresql.org/docs/postgres/functions-matching.html#FUNCTIONS-POSIX-REGEXP Note that those are probably a little different from previous releases because the regex engine has been changed. -- Alvaro Herrera (<[EMAIL PROTECTED]>) "I dream about dreams about dreams", sang the nightingale under the pale moon (Sandman) ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] reuse sysids security hole?
On Tue, Aug 12, 2003 at 04:01:33PM -0400, Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Can I have a TODO for this? > > * Prevent accidental re-use of sysids for dropped users and groups > > The other part of the thread was something like > > * Prevent dropping user that still owns objects, or auto-drop the objects What about the use of a shared sequence object to generate sysids? -- Alvaro Herrera (<[EMAIL PROTECTED]>) "The Gord often wonders why people threaten never to come back after they've been told never to return" (www.actsofgord.com) ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: Parsing speed (was Re: [HACKERS] pgstats_initstats() cost)
On Tue, Aug 12, 2003 at 03:36:07PM -0400, Tom Lane wrote: > This leaves us with a bit of a problem, though, because there isn't any > libpq API that allows access to this speedup. I put in a routine to > support Parse/Bind/Execute so that people could use out-of-line > parameters for safety reasons --- but there's no function to do > Bind/Execute against a pre-existing prepared statement. (I had to make > a hacked version of libpq to do the above testing.) > > I'm beginning to think that was a serious omission. I'm tempted to fix > it, even though we're past feature freeze for 7.4. Comments? Please do. It could be argued that the feature is already there, and that the fact that there's no way to use it through libpq is actually a bug. -- Alvaro Herrera (<[EMAIL PROTECTED]>) "Hay que recordar que la existencia en el cosmos, y particularmente la elaboración de civilizaciones dentre de él no son, por desgracia, nada idílicas" (Ijon Tichy) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] two buglets: createlang and pg_get_triggerdef
Hackers, Two buglets: The first one is in createlang, trying to create a language without enough permission: $ createlang -d alvherre plpgsql createlang: language installation failed: ERROR: c: permission denied What's the "c" it's complaning about? The second one is in pg_get_triggerdef(): alvherre=> create table test (foo int); CREATE TABLE alvherre=> create function foofun() returns trigger as 'select 1' language plpgsql; CREATE FUNCTION alvherre=> create trigger my_little_trigger before update on test execute procedure foofun(); CREATE TRIGGER alvherre=> \d test Table "public.test" Column | Type | Modifiers +-+--- foo| integer | Triggers: my_little^trigger BEFORE UPDATE ON test FOR EACH STATEMENT EXECUTE PROCEDURE foofun() Note that the 9th character has been changed to "^". I've seen the 9th character change in all triggers here. If I look at pg_trigger the name is fine: alvherre=> select tgname from pg_trigger where tgname='my_little_trigger'; tgname --- my_little_trigger (1 row) This is not on latest CVS, but I haven't seem them reported nor fixed. -- Alvaro Herrera (<[EMAIL PROTECTED]>) "El sentido de las cosas no viene de las cosas, sino de las inteligencias que las aplican a sus problemas diarios en busca del progreso." (Ernesto Hernández-Novich) ---(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] Error messages --- now that we've got it, do you like
On Wed, Jul 30, 2003 at 10:33:55PM -0400, Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Tom, you saw this suggestion, right? > > I didn't hear anyone else agreeing with it ... Well, if this needs a vote, I'm for something like maximum/default/minimum rather than the way it currently is. Saying "verbosity verbose" or "verbosity terse" doesn't feel right, while "verbosity maximum" makes sense, to me anyway. -- Alvaro Herrera (<[EMAIL PROTECTED]>) Thou shalt study thy libraries and strive not to reinvent them without cause, that thy code may be short and readable and thy days pleasant and productive. (7th Commandment for C Programmers) ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] CREATE TABLE AS ... EXECUTE
Hackers, Is there a way to create a table from a prepared statement? CREATE TABLE AS explicitly says you have to use a SELECT statement, and the SELECT INTO syntax doesn't seem to allow the use of a prepared statement either. I don't see a way to use the prepared statement as a function nor as a "table" (SELECT ... FROM EXECUTE) Of course, the prepared statement is a SELECT statement. Am I missing something, or it is supposed to be like this? I don't _need_ this (I can use a regular SQL function), but... -- Alvaro Herrera (<[EMAIL PROTECTED]>) "¿Qué importan los años? Lo que realmente importa es comprobar que a fin de cuentas la mejor edad de la vida es estar vivo" (Mafalda) ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] default locale considered harmful? (was Re: [GENERAL]
On Thu, Jun 05, 2003 at 09:44:21AM -0600, scott.marlowe wrote: > On Thu, 5 Jun 2003, Nigel J. Andrews wrote: > Everything Nigel just wrote plus one thing. > > If it comes down to it, we could always require a --locale setting and > refuse to initdb without it. That way, whether it's in an RPM or from > source, somebody somewhere along the line has to choose something. Yeah, that way the RPM guys would put the --locale taking the locale from the environment and you're back to ground zero. There's no point in forcing things down the throat of users using this kind of mechanisms, because someone is going to automate the thing along the way. What is needed is a way to make the user aware of his system's configuration. -- Alvaro Herrera (<[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] Help needed in testing my code.
On Wed, May 28, 2003 at 12:59:56PM +0200, Sailesh Krishnamurthy wrote: > elog(NOTICE should send NOTICE messages to the psql client (I think !) > while elog(LOG while only send it to the logfile you might have > specified while starting the postmaster Whether a given elog level is sent to the postmaster log and to the client, is controlled by client_min_messages and server_min_messages. At least in recent sources, that is. -- Alvaro Herrera (<[EMAIL PROTECTED]>) We take risks not to escape from life, but to prevent life escaping from us. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] vacuum analyze corrupts database
On Wed, May 28, 2003 at 09:04:18AM -0400, Michael Brusser wrote: > > Well, first thing I'd ask is whether the other installation is using > > the same locale settings. > Oh, yes, I am very sure of that. Note that while the machine reports the C locale, pg_controldata actually said the database was en_US.iso8859-1 or something like that. Make sure pg_controldata reports the same on the other machine... -- Alvaro Herrera (<[EMAIL PROTECTED]>) "The eagle never lost so much time as when he submitted to learn from the crow." (William Blake, citado por Nobody) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
