Re: [HACKERS] operator exclusion constraints
On Sun, 2009-11-01 at 22:42 +, Simon Riggs wrote: The current patch writes the syntax like this EXCLUSION USING gist (c CHECK WITH ) makes it look like a table constraint, yet it clearly refers to a single column. That looks very clumsy to read, to my eyes. I think the word CHECK should be avoided completely in this syntax, to avoid confusion with CHECK constraints. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal - temporal contrib module
Jeff Davis pg...@j-davis.com writes: If I understand what you're saying, you're alluding to a type where you can do things like: RANGE(timestamptz) which would be equivalent to a PERIOD. The RANGE approach sounds so much better from here, as I have the prefix_range example nearby... it'd be nice if it could benefit. Typmod almost provides enough flexibility, but it can't store a full OID, so we'd need to get creative. There are probably some other issues here as well, because the current type system isn't really designed for this kind of thing. Do you have any ideas or guidance here? When talking about the extension facility it has been said PostGIS is being creative for lacking of typmod capabilities. It could mean it's past time for a typmod reality check? Regards, -- dim -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] backup_label in a crash recovery
Fujii Masao wrote: When a crash occurs before calling pg_stop_backup(), the subsequent crash recovery causes the FATAL error and outputs the following HINT message. If you are not restoring from a backup, try removing the file \%s/backup_label\. I wonder why backup_label isn't automatically removed in normal crash recovery case. Is this for the fail-safe protection; prevent admin from restoring from a backup wrongly without creating recovery.conf? Or another? If that's intentional, a clusterware for shared disk failover system should remove backup_label whenever doing failover. Otherwise, when a crash occurs during online-backup, the failover would fail. I do not know if there is a good reason why the server does not ignore backup_label if recovery.conf is not present. But as it is, any failover system should definitely remove backup_label. Yours, Laurenz Albe -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Architecture of walreceiver (Streaming Replication)
Hi, Recently, the development of SR is not progressing because of the indecision on whether walreceiver should be a subprocess of the startup process (i.e., a stand-alone program), or of postmaster. Since time is running out, I'd like to discuss about this and advance the project. The related threads are: http://archives.postgresql.org/pgsql-hackers/2009-09/msg01101.php http://archives.postgresql.org/pgsql-hackers/2009-09/msg01291.php IMO, walreceiver should be a subprocess of postmaster for the following reasons. 1. It's not easy to give a GUC parameter to a stand-alone walreceiver program. A simple approach is giving a parameter as a command-line argument. But this wouldn't cover a reload of parameter. 2. It's not easy to treat the log messages generated by a stand-alone walreceiver as well as the other postgres messages. A straightforward approach is that the startup process passes along the messages to the logger process. But this is not simple. I agree that a stand-alone walreceiver is useful for some cases. But I think that it's sufficient to provide that as contrib or pgfoundry tool. Not need to provide that in core. The communication interface to walsender is going to be provided as libpq, so it's not difficult to implement such a stand-alone tool. Thought? Please feel free to comment. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] alpha2 bundled -- please verify
On Wed, 2009-10-28 at 22:28 +0200, Devrim GÜNDÜZ wrote: Peter, could you please provide md5sum for alpha2 tarball? I know we missed in alpha1. It would be better if the original packager would upload the md5sum. I was struggling internally with this one, because the tools currently in use are FreeBSD-specific (md5 vs md5sum on Linux), and I would like to be able to have a portable, reproducible release build procedure. I can add them, but I would like to have a better solution in the future. (For example: We consider the md5 file not part of the release but part of the FTP server. Then moving a release onto the FTP server causes the md5 file to be created.) Also, I'll be happy if you can also upload .bz2 file (for the lazy RPM packages who does not want to play with his spec files a lot). Done. I'll also add that to the build scripts for the new alpha. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] alpha2 bundled -- please verify
On Mon, 2009-11-02 at 13:02 +0200, Peter Eisentraut wrote: Also, I'll be happy if you can also upload .bz2 file (for the lazy RPM packages who does not want to play with his spec files a lot). Done. I'll also add that to the build scripts for the new alpha. Thanks Peter. Regards, -- Devrim GÜNDÜZ, RHCE Command Prompt - http://www.CommandPrompt.com devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz signature.asc Description: This is a digitally signed message part
Re: [HACKERS] operator exclusion constraints
On Sun, 2009-11-01 at 18:07 -0500, Tom Lane wrote: Simon Riggs si...@2ndquadrant.com writes: The syntax be easier to read if it was stated as a comparison e.g. in the circle example CHECK ( NOT (NEW.c c)) USING GIST I don't think this is a good idea at all. NEW is a nonstandard Postgres-ism, and introducing it into this syntax doesn't seem very future-proof to me. What's more, the above is not in the least analogous to a regular CHECK constraint, because there's some implicit notion of c ranging over all other rows, which is not what is meant by the same column reference in a CHECK constraint. I agree that the proposed syntax is a bit awkward, but this isn't better. Agreed. Just looking for readable, future-proof syntax. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Architecture of walreceiver (Streaming Replication)
On Nov 2, 2009, at 5:06 AM, Fujii Masao masao.fu...@gmail.com wrote: Hi, Recently, the development of SR is not progressing because of the indecision on whether walreceiver should be a subprocess of the startup process (i.e., a stand-alone program), or of postmaster. Since time is running out, I'd like to discuss about this and advance the project. The related threads are: http://archives.postgresql.org/pgsql-hackers/2009-09/msg01101.php http://archives.postgresql.org/pgsql-hackers/2009-09/msg01291.php IMO, walreceiver should be a subprocess of postmaster for the following reasons. 1. It's not easy to give a GUC parameter to a stand-alone walreceiver program. A simple approach is giving a parameter as a command-line argument. But this wouldn't cover a reload of parameter. 2. It's not easy to treat the log messages generated by a stand-alone walreceiver as well as the other postgres messages. A straightforward approach is that the startup process passes along the messages to the logger process. But this is not simple. I agree that a stand-alone walreceiver is useful for some cases. But I think that it's sufficient to provide that as contrib or pgfoundry tool. Not need to provide that in core. The communication interface to walsender is going to be provided as libpq, so it's not difficult to implement such a stand-alone tool. Thought? Please feel free to comment. I agree. A stand-alone tool seems like a good idea (which is why I proposed it) but I don't think that should mean that we can't have a tightly integrated core facility. We can decide later whether there it is helpful for those things to share code; right now, we should focus on getting an initial version of this feature out the door. Speaking of getting things out the door, what's up with Hot Standby? It seemed like the outstanding issues were just about dealt with, and then the discussion died off... ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] backup_label in a crash recovery
Fujii Masao masao.fu...@gmail.com writes: I wonder why backup_label isn't automatically removed in normal crash recovery case. Removing it automatically could be catastrophic if done incorrectly, no? If that's intentional, a clusterware for shared disk failover system should remove backup_label whenever doing failover. It would be no less catastrophic if done incorrectly from outside the postmaster; see for example the problems people have had historically with startup scripts that think they should remove postmaster.pid. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] libpq - extending PQexecParams/PQexecPrepared to specify resultFormat for individual result columns
Hi guys, I hacked PostgreSQL 8.4.1 libpq and added a new function to specify resultFormat for individual result columns. Are you interested in a patch? (http://www.postgresql.org/docs/8.4/interactive/libpq-exec.html says: There is not currently a provision to obtain different result columns in different formats, although that is possible in the underlying protocol. So I made this possible.) Kind regards, Ivosh -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] libpq - extending PQexecParams/PQexecPrepared to specify resultFormat for individual result columns
On Mon, Nov 2, 2009 at 6:00 AM, Ivo Raisr iv...@ivosh.net wrote: Hi guys, I hacked PostgreSQL 8.4.1 libpq and added a new function to specify resultFormat for individual result columns. Are you interested in a patch? (http://www.postgresql.org/docs/8.4/interactive/libpq-exec.html says: There is not currently a provision to obtain different result columns in different formats, although that is possible in the underlying protocol. So I made this possible.) How exactly did you do it? You can't change the arguments of existing libpq functions, you would have had to add new ones... merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Architecture of walreceiver (Streaming Replication)
Fujii Masao escreveu: IMO, walreceiver should be a subprocess of postmaster for the following reasons. +1. I agree that the first version should be as close as possible to postmaster. My points are: (i) it will be easier to install (no need to install another third-party software), (ii) it will be easier to administrate (the options will be available in one central point -- postgresql.conf), and (iii) it will be easier to control (it is a postmaster subprocess). But I see some value if it would be possible to design it in a way that other third-party softwares could replace it completely (even if it couldn't take advantage of some postmaster features). Of course, there is no need to develop such a POC external walreceiver tool. You just need to have in mind that available interfaces should be accessible by external tools. If someone decides to code a tool to mimic walreceiver but with some aditional features such as wal filtering then (s)he is free to do it because we provide entry points in the API. BTW, are you going to submit another WIP patch for next commitfest? -- Euler Taveira de Oliveira http://www.timbira.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Architecture of walreceiver (Streaming Replication)
On Mon, Nov 2, 2009 at 10:14 AM, Euler Taveira de Oliveira eu...@timbira.com wrote: BTW, are you going to submit another WIP patch for next commitfest? Well, Heikki was going to keep working on this and Hot Standby between CommitFests until it gets committed, but things seem to be stalled at the moment, possibly because Heikki is tied up with internal EnterpriseDB projects. I don't think the hold-up is with Fujii Masao. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] libpq - extending PQexecParams/PQexecPrepared to specify resultFormat for individual result columns
On Mon, Nov 02, 2009 at 12:00:29PM +0100, Ivo Raisr wrote: Hi guys, I hacked PostgreSQL 8.4.1 libpq and added a new function to specify resultFormat for individual result columns. Are you interested in a patch? New features only go into git head (aka CVS TIP), so for future reference, only patch that. One of the ways PostgreSQL has earned its reputation for stability is by never adding a feature to a released version :) (http://www.postgresql.org/docs/8.4/interactive/libpq-exec.html says: There is not currently a provision to obtain different result columns in different formats, although that is possible in the underlying protocol. So I made this possible.) How? Cheers, David. -- David Fetter da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] libpq - extending PQexecParams/PQexecPrepared to specify resultFormat for individual result columns
Ivo Raisr wrote: Hi guys, I hacked PostgreSQL 8.4.1 libpq and added a new function to specify resultFormat for individual result columns. Are you interested in a patch? (http://www.postgresql.org/docs/8.4/interactive/libpq-exec.html says: There is not currently a provision to obtain different result columns in different formats, although that is possible in the underlying protocol. So I made this possible.) Can you explain the use case for this? Have you investigated libpqtypes? -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Some notes about Param handling with Oracle style plpgsql variables
One of the interesting properties of Oracle-compatible variable references in plpgsql is that the set of variables referenced by a given query could change during a forced replan. For example, consider declare x int; r record; ... for r in select x,y from tab loop ... If tab contains a column x then the x reference in the SELECT refers to tab.x; if not, it refers to the plpgsql variable x. So when first executing the SELECT we might find that it requires a Param reference to the plpgsql variable, and then after a replan is forced by ALTER TABLE tab ADD COLUMN x, there is no need for the Param anymore. Or vice versa. This kinda calls into question whether the Oracle way is actually a good idea or not; but my purpose here is not to debate that, just to look at what it takes to implement it. Currently, plpgsql generates a list of the variables referenced by any SQL statement or expression immediately upon seeing the text, before it's ever even fed to the core parser. I had been envisioning having the parser callback hook construct the list on-the-fly during parsing, but the possibility that the list will change from time to time means that other changes are needed too. Notably: 1. plancache.c does not have any provision for letting the Param type array associated with a stored statement change when the statement is replanned due to SI invalidation. 2. The control flow for a replan is that plpgsql calls SPI_execute_plan, which calls RevalidateCachedPlan, which does the replan if the cached plan is discovered to be stale. However, plpgsql already had to set up the list of actual parameter values before it called SPI_execute_plan, which means it is *way* too late to change the list of required Params even if plancache let us do it. After chewing on these facts for awhile, I am thinking that the best solution is for plpgsql to abandon the notion of a predetermined list of parameters for a SQL query altogether. What that list basically provides is a mapping from Param numbers ($n) to plpgsql datum numbers (indexes in the list of a plpgsql function's variables). We could make that mapping always be one-to-one, since there's no real reason that the Params available to a query have to be consecutively numbered. So the transformColumnRef hook would just pass back a Param using the referenced variable's datum number as paramid; it wouldn't bother at all with building a data structure listing the specific variables actually used in the query. As far as plancache goes, it would therefore always see a null array of Param type OIDs associated with a plpgsql-generated query, and we'd not have to provide a way to update that. (We'd still keep the ability to store such an array, because most other callers of plancache will still want a fixed list of Params.) What we'd have to add to plancache instead is the ability to install caller-determined parser callback hooks when it is calling the parser for a replan. This seems fairly easy to do --- I'm envisioning a sort of meta-hook function that gets called with the new ParseState and can insert hook function pointers in it. The other issue with this is what to do at runtime. We could do it with no other changes if we had plpgsql always set up Values/Nulls arrays listing *every* datum's current value. This seems a bit brute-force though --- it could be slow in a function with a lot of variables, and in most cases any specific query or expression would not need most of those values. What I think we should do instead is extend the ParamListInfo structure to add a callback hook function that populates individual ParamExternData array entries on-demand. The core executor would call the hook when it tried to fetch the value of a Param that was currently invalid (ptype == 0). So the hook would be invoked only once per query per referenced parameter, which shouldn't be much overhead. Another interesting property of this approach is that it'd fix the longstanding user complaint that constructions like if (TG_OP = 'INSERT' and NEW.foo = 'bar') ... fail prematurely. The executor would never demand the value of NEW.foo, and thus not fail, if TG_OP isn't INSERT. Comments? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PL/Perl backed crashed during spi_exec_query
On Oct 31, 2009, at 7:30 PM, Tom Lane wrote:
Alexey Klyukin al...@commandprompt.com writes:
One of our customers is running 8.2.14 and use a couple of pl/perl
and
pl/perlu functions written by CMD. Everything worked normally until
they tried to call one particular pl/perl function from pl/perl via
spi. It appears that a die call inside the callee just crashes the
backend.
I think the critical point is actually that you're calling plperl from
plperlu, and we're being careless about restoring the former
interpreter
selection on error exit. The attached patch moves the responsibility
for that into plperl_call_handler, which already has a suitable
PG_TRY block.
The patch solves the problem, thank you!
regards, tom lane
Index: plperl.c
===
RCS file: /cvsroot/pgsql/src/pl/plperl/plperl.c,v
retrieving revision 1.152
diff -c -r1.152 plperl.c
*** plperl.c28 Sep 2009 17:31:12 - 1.152
--- plperl.c31 Oct 2009 17:27:14 -
***
*** 380,390
}
}
!
static void
restore_context(bool old_context)
{
! if (trusted_context != old_context)
{
if (old_context)
PERL_SET_CONTEXT(plperl_trusted_interp);
--- 380,392
}
}
! /*
! * Restore previous interpreter selection, if two are active
! */
static void
restore_context(bool old_context)
{
! if (interp_state == INTERP_BOTH trusted_context != old_context)
{
if (old_context)
PERL_SET_CONTEXT(plperl_trusted_interp);
***
*** 870,878
plperl_call_handler(PG_FUNCTION_ARGS)
{
Datum retval;
! plperl_call_data *save_call_data;
- save_call_data = current_call_data;
PG_TRY();
{
if (CALLED_AS_TRIGGER(fcinfo))
--- 872,880
plperl_call_handler(PG_FUNCTION_ARGS)
{
Datum retval;
! plperl_call_data *save_call_data = current_call_data;
! boololdcontext = trusted_context;
PG_TRY();
{
if (CALLED_AS_TRIGGER(fcinfo))
***
*** 883,893
--- 885,897
PG_CATCH();
{
current_call_data = save_call_data;
+ restore_context(oldcontext);
PG_RE_THROW();
}
PG_END_TRY();
current_call_data = save_call_data;
+ restore_context(oldcontext);
return retval;
}
***
*** 1226,1232
Datum retval;
ReturnSetInfo *rsi;
SV *array_ret = NULL;
- boololdcontext = trusted_context;
ErrorContextCallback pl_error_context;
/*
--- 1230,1235
***
*** 1376,1384
if (array_ret == NULL)
SvREFCNT_dec(perlret);
- current_call_data = NULL;
- restore_context(oldcontext);
-
return retval;
}
--- 1379,1384
***
*** 1391,1397
Datum retval;
SV *svTD;
HV *hvTD;
- boololdcontext = trusted_context;
ErrorContextCallback pl_error_context;
/*
--- 1391,1396
***
*** 1491,1498
if (perlret)
SvREFCNT_dec(perlret);
- current_call_data = NULL;
- restore_context(oldcontext);
return retval;
}
--- 1490,1495
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Some notes about Param handling with Oracle style plpgsql variables
2009/11/2 Tom Lane t...@sss.pgh.pa.us: One of the interesting properties of Oracle-compatible variable references in plpgsql is that the set of variables referenced by a given query could change during a forced replan. For example, consider declare x int; r record; ... for r in select x,y from tab loop ... If tab contains a column x then the x reference in the SELECT refers to tab.x; if not, it refers to the plpgsql variable x. So when first executing the SELECT we might find that it requires a Param reference to the plpgsql variable, and then after a replan is forced by ALTER TABLE tab ADD COLUMN x, there is no need for the Param anymore. Or vice versa. This kinda calls into question whether the Oracle way is actually a good idea or not; but my purpose here is not to debate that, just to look at what it takes to implement it. Currently, plpgsql generates a list of the variables referenced by any SQL statement or expression immediately upon seeing the text, before it's ever even fed to the core parser. I had been envisioning having the parser callback hook construct the list on-the-fly during parsing, but the possibility that the list will change from time to time means that other changes are needed too. Notably: 1. plancache.c does not have any provision for letting the Param type array associated with a stored statement change when the statement is replanned due to SI invalidation. 2. The control flow for a replan is that plpgsql calls SPI_execute_plan, which calls RevalidateCachedPlan, which does the replan if the cached plan is discovered to be stale. However, plpgsql already had to set up the list of actual parameter values before it called SPI_execute_plan, which means it is *way* too late to change the list of required Params even if plancache let us do it. After chewing on these facts for awhile, I am thinking that the best solution is for plpgsql to abandon the notion of a predetermined list of parameters for a SQL query altogether. What that list basically provides is a mapping from Param numbers ($n) to plpgsql datum numbers (indexes in the list of a plpgsql function's variables). We could make that mapping always be one-to-one, since there's no real reason that the Params available to a query have to be consecutively numbered. So the transformColumnRef hook would just pass back a Param using the referenced variable's datum number as paramid; it wouldn't bother at all with building a data structure listing the specific variables actually used in the query. As far as plancache goes, it would therefore always see a null array of Param type OIDs associated with a plpgsql-generated query, and we'd not have to provide a way to update that. (We'd still keep the ability to store such an array, because most other callers of plancache will still want a fixed list of Params.) What we'd have to add to plancache instead is the ability to install caller-determined parser callback hooks when it is calling the parser for a replan. This seems fairly easy to do --- I'm envisioning a sort of meta-hook function that gets called with the new ParseState and can insert hook function pointers in it. The other issue with this is what to do at runtime. We could do it with no other changes if we had plpgsql always set up Values/Nulls arrays listing *every* datum's current value. This seems a bit brute-force though --- it could be slow in a function with a lot of variables, and in most cases any specific query or expression would not need most of those values. What I think we should do instead is extend the ParamListInfo structure to add a callback hook function that populates individual ParamExternData array entries on-demand. The core executor would call the hook when it tried to fetch the value of a Param that was currently invalid (ptype == 0). So the hook would be invoked only once per query per referenced parameter, which shouldn't be much overhead. Another interesting property of this approach is that it'd fix the longstanding user complaint that constructions like if (TG_OP = 'INSERT' and NEW.foo = 'bar') ... fail prematurely. The executor would never demand the value of NEW.foo, and thus not fail, if TG_OP isn't INSERT. good idea. regards Pavel Comments? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] per-tablespace random_page_cost/seq_page_cost
Robert Haas escribió: I don't see anything in this code that is very rel-specific, so I think it would be possible to implement spcoptions by just defining RELOPT_KIND_TABLESPACE and ignoring the irony, but that has enough of an unsavory feeling that I'm sure someone is going to complain about it... I suppose we could go through and systematically rename all instances of reloptions to ent(ity)options or storageoptions or gen(eric)options or somesuch... Maybe I missed part of the discussion, but do these really need to be handled like reloptions instead of like datoptions? Perhaps the deciding factor is that we want to parse them once and store them in a cache, so like reloptions; the others are used once per connection and then thrown away. If this is the case, then I think we could just decide that their name is reloptions due to hysterical reasons and be done with it. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Some notes about Param handling with Oracle style plpgsql variables
On Mon, Nov 2, 2009 at 11:31 AM, Tom Lane t...@sss.pgh.pa.us wrote: Another interesting property of this approach is that it'd fix the longstanding user complaint that constructions like if (TG_OP = 'INSERT' and NEW.foo = 'bar') ... fail prematurely. The executor would never demand the value of NEW.foo, and thus not fail, if TG_OP isn't INSERT. I don't really know enough to comment on the best way to go about this project overall, but fixing this would be incredibly nice, if it can be done without too much damage. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] operator exclusion constraints
On Mon, 2009-11-02 at 07:38 +, Simon Riggs wrote: It bothers me that we would have completely separate syntax for this feature as opposed to normal SQL. It also doesn't make it easy to interpret from the business statement to the implementation. Notice that the , above means AND. Yes, in that way, it's similar to a UNIQUE constraint, e.g. UNIQUE (a, b). The more columns you add, the more permissive the constraint. How would we use an OR conditional? Specify multiple constraints. How would we express the wish to use a partial index? EXCLUSION (...) WHERE (...) The perens are actually required around the predicate in this case, due to syntactic problems. How would I express a bidding rule: Only allow bids that are better than the highest bid so far EXCLUSION (item CHECK WITH =, bid_price CHECK WITH ) That would be a cool feature, unfortunately it won't work in the current form. This constraint is only enforced on index insert -- imagine what confusion would be caused when: UPDATE foo SET third_column = 7 ... If that's a HOT update, it wouldn't re-check the bid_price. If it turns into a cold update, it would reject the update because the bid_price is no longer the highest. Did I get the the right way around? The above problem essentially means we only allow commutative operators, which avoids this source of confusion. Interestingly, reflexive operators aren't required. So, if is searchable, you can have the opposite of unique: all values must be the same. That might be interesting for something like: EXCLUSION(room CHECK WITH =, during CHECK WITH , student_grade CHECK WITH ) To ensure that a shared room isn't shared between students of different grades. Not the most compelling use case, but I could imagine something along these lines being useful. Maybe a better example would involve sheep and wolves ;) How would I specify a tree that has only 2 down branches at any node, 'left' and 'right'? I'm not sure I understand this exactly. If the left or right is explcitly a part of the tuple, I think it can be done with unique. If not, and you're looking for a maximum of two tuples, you can see my ill-fated extension to this feature here: http://archives.postgresql.org/pgsql-hackers/2009-11/msg00016.php As Tom pointed out, most use cases would not have a constant limit throughout the table. If you do have such a use case, you can revive the proposal. Not sure that if we submitted this to SQL Standard committee that it would be accepted as is. There are implementation details bubbling up to the user-visible behavior, and I share your concern. The SQL committee would never care about these implementation details, and I wish we didn't have to, either. The machinism that I've employed searches (using a dirty snapshot) for all of the physical tuples that cause a logical conflict with the physical tuple currently being added. If found, it uses physical information from those tuples, like visibility information, to determine whether to wait, and on whom to wait. After waiting it may either proceed or abort. If we move closer to a nice, clean query to express the constraint, it gets very difficult to tell which physical tuple is responsible for the conflict. If we don't know what physical tuple is causing the conflict, we have to serialize all writes. Additionally, the more it looks like a query, the more we have to tell users follow this template -- which will just lead to confusion and disappointment for users who think we've implemented SQL ASSERT (which we haven't). Although the current syntax isn't great, it is declarative, and it does allow a variety of constraints. I certainly welcome ideas that will make a better trade-off here. At the end, I just want a feature that can implement temporal keys. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] operator exclusion constraints
On Mon, 2009-11-02 at 08:25 +, Peter Eisentraut wrote: I think the word CHECK should be avoided completely in this syntax, to avoid confusion with CHECK constraints. This is an easy change. I don't have a strong opinion, so the only thing I can think to do is ask for a vote. Do you have a specific alternative in mind? How about just WITH? Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Renaming conversion procs (was Re: [GENERAL] Error on compile for Windows)
Steve Atkins st...@blighty.com writes: I've also seen it with winzip. Again, ISTR that the exact limits were obscure but that restricting the path to less than 100 characters avoided any problems. Hmm. It strikes me that the names seen by tar include postgresql-x.y.z/. The only file paths that approach 100 characters on that basis as of 8.4.1 are postgresql-8.4.1/src/backend/utils/mb/conversion_procs/utf8_and_shift_jis_2004/utf8_and_shift_jis_2004.c postgresql-8.4.1/src/backend/utils/mb/conversion_procs/utf8_and_euc_jis_2004/utf8_and_euc_jis_2004.c postgresql-8.4.1/src/backend/utils/mb/conversion_procs/euc_jis_2004_and_shift_jis_2004/euc_jis_2004_and_shift_jis_2004.c The first and third of these have in fact been reported as trouble spots. AFAIR the second has not, but it's exactly 100 characters, which would explain why it works ... or will work till we get to two digits in the minor release number, anyway :-(. So that seems to validate your theory. If we want to set an upper limit of 100 characters, and allow for release numbers up to 99.99.99, then the maximum length for conversion_procs file names would be 19 characters (plus .c), and the same for their directories. So we could rename these to, say, utf8_and_sjis2004 utf8_and_euc2004 euc2004_sjis2004 This would be an easy change to make going forward (other than loss of CVS history, but I'm not terribly worried about that for these files). We could not so easily back-patch it because the .so filenames are already embedded in installations' pg_proc tables. Personally I'd be satisfied if it's fixed for 8.5 and beyond --- comments? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] operator exclusion constraints
Jeff Davis pg...@j-davis.com writes: On Mon, 2009-11-02 at 08:25 +, Peter Eisentraut wrote: I think the word CHECK should be avoided completely in this syntax, to avoid confusion with CHECK constraints. This is an easy change. I don't have a strong opinion, so the only thing I can think to do is ask for a vote. Do you have a specific alternative in mind? How about just WITH? I think we had that discussion already, and rejected using WITH by itself because it was so totally devoid of suggestion of what it was the system would do with the expression or operator. If we don't want to introduce a new reserved word it's difficult to find alternatives :-(. One thing that just came to mind is that we might be able to do something like EXCLUSION (expr CHECK NOT operator) or EXCLUSION (expr CONSTRAIN NOT operator) I like the NOT here because CHECK NOT = seems to convey pretty clearly what it is you are checking for. Because NOT is reserved and can't appear as a connective, I think that this approach might allow a non-reserved leading word, thus possibly the second variant would work without reserving CONSTRAIN. I have not tested whether bison agrees with me though ;-). In any case I think CHECK NOT = reads pretty well, and don't feel a strong urge to use some other word there. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Architecture of walreceiver (Streaming Replication)
Robert Haas wrote: On Mon, Nov 2, 2009 at 10:14 AM, Euler Taveira de Oliveira eu...@timbira.com wrote: BTW, are you going to submit another WIP patch for next commitfest? Well, Heikki was going to keep working on this and Hot Standby between CommitFests until it gets committed, but things seem to be stalled at the moment, possibly because Heikki is tied up with internal EnterpriseDB projects. I don't think the hold-up is with Fujii Masao. Right. I got dragged away into other stuff for the last week or so. wrt. synchronous replication, if someone else has the cycles to look at it, that would be great. I got stuck on the postmaster-process or not question Fujii raised again now, not being able to decide. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Architecture of walreceiver (Streaming Replication)
Euler Taveira de Oliveira wrote: Fujii Masao escreveu: IMO, walreceiver should be a subprocess of postmaster for the following reasons. +1. I agree that the first version should be as close as possible to postmaster. My points are: (i) it will be easier to install (no need to install another third-party software), (ii) it will be easier to administrate (the options will be available in one central point -- postgresql.conf), and (iii) it will be easier to control (it is a postmaster subprocess). None of these points are really for or against either approach. In any case, we would ship with all the required components, so no need to install 3rd party software. The recovery related options would come from recovery.conf in both models, although that could be changed if we wanted to. Not sure what easier to control (iii) means, although admittedly it's a bit tricky to make it walreceiver behave correctly as a subprocess of the startup process, making sure it responds to shutdown requests etc. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] operator exclusion constraints
On Mon, 2009-11-02 at 13:12 -0500, Tom Lane wrote: Jeff Davis pg...@j-davis.com writes: On Mon, 2009-11-02 at 08:25 +, Peter Eisentraut wrote: I think the word CHECK should be avoided completely in this syntax, to avoid confusion with CHECK constraints. This is an easy change. I don't have a strong opinion, so the only thing I can think to do is ask for a vote. Do you have a specific alternative in mind? How about just WITH? I think we had that discussion already, and rejected using WITH by itself because it was so totally devoid of suggestion of what it was the system would do with the expression or operator. If we don't want to introduce a new reserved word it's difficult to find alternatives :-(. One thing that just came to mind is that we might be able to do something like EXCLUSION (expr CHECK NOT operator) or EXCLUSION (expr CONSTRAIN NOT operator) I like the NOT here because CHECK NOT = seems to convey pretty clearly what it is you are checking for. Because NOT is reserved and can't appear as a connective, I think that this approach might allow a non-reserved leading word, thus possibly the second variant would work without reserving CONSTRAIN. I have not tested whether bison agrees with me though ;-). In any case I think CHECK NOT = reads pretty well, and don't feel a strong urge to use some other word there. Yep, like the NOT. Other ideas EXCLUSION (expr NOT operator) CONSTRAINT (expr NOT operator ALL ROWS) -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Re: Renaming conversion procs (was Re: [GENERAL] Error on compile for Windows)
On Mon, Nov 2, 2009 at 18:54, Tom Lane t...@sss.pgh.pa.us wrote: Steve Atkins st...@blighty.com writes: I've also seen it with winzip. Again, ISTR that the exact limits were obscure but that restricting the path to less than 100 characters avoided any problems. Hmm. It strikes me that the names seen by tar include postgresql-x.y.z/. The only file paths that approach 100 characters on that basis as of 8.4.1 are postgresql-8.4.1/src/backend/utils/mb/conversion_procs/utf8_and_shift_jis_2004/utf8_and_shift_jis_2004.c postgresql-8.4.1/src/backend/utils/mb/conversion_procs/utf8_and_euc_jis_2004/utf8_and_euc_jis_2004.c postgresql-8.4.1/src/backend/utils/mb/conversion_procs/euc_jis_2004_and_shift_jis_2004/euc_jis_2004_and_shift_jis_2004.c The first and third of these have in fact been reported as trouble spots. AFAIR the second has not, but it's exactly 100 characters, which would explain why it works ... or will work till we get to two digits in the minor release number, anyway :-(. So that seems to validate your theory. If we want to set an upper limit of 100 characters, and allow for release numbers up to 99.99.99, then the maximum length for conversion_procs file names would be 19 characters (plus .c), and the same for their directories. So we could rename these to, say, utf8_and_sjis2004 utf8_and_euc2004 euc2004_sjis2004 This would be an easy change to make going forward (other than loss of CVS history, but I'm not terribly worried about that for these files). We could not so easily back-patch it because the .so filenames are already embedded in installations' pg_proc tables. Personally I'd be satisfied if it's fixed for 8.5 and beyond --- comments? Seems like this would be a major PITA for packagers and end-user. And it would be an issue for the vast majority of our users - who use binary packages on whatever platform they're on. And that only to help those that have a broken (or severely limited) tar version, *and* try to build from source. Thus, +1 for doing this for 8.5 and beyond only. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Some notes about Param handling with Oracle style plpgsql variables
2009/11/2 Tom Lane t...@sss.pgh.pa.us: One of the interesting properties of Oracle-compatible variable references in plpgsql is that the set of variables referenced by a given query could change during a forced replan. For example, consider declare x int; r record; ... for r in select x,y from tab loop ... If tab contains a column x then the x reference in the SELECT refers to tab.x; if not, it refers to the plpgsql variable x. So when first executing the SELECT we might find that it requires a Param reference to the plpgsql variable, and then after a replan is forced by ALTER TABLE tab ADD COLUMN x, there is no need for the Param anymore. Or vice versa. This kinda calls into question whether the Oracle way is actually a good idea or not; but my purpose here is not to debate that, just to look at what it takes to implement it. This is reason, why I would to see third mode (incompatible with Oracle or pg), that raise error, when it detects any intersecting identifiers. I understand so this mode should not be default, but personally I'll use it everywhere. Pavel Currently, plpgsql generates a list of the variables referenced by any SQL statement or expression immediately upon seeing the text, before it's ever even fed to the core parser. I had been envisioning having the parser callback hook construct the list on-the-fly during parsing, but the possibility that the list will change from time to time means that other changes are needed too. Notably: 1. plancache.c does not have any provision for letting the Param type array associated with a stored statement change when the statement is replanned due to SI invalidation. 2. The control flow for a replan is that plpgsql calls SPI_execute_plan, which calls RevalidateCachedPlan, which does the replan if the cached plan is discovered to be stale. However, plpgsql already had to set up the list of actual parameter values before it called SPI_execute_plan, which means it is *way* too late to change the list of required Params even if plancache let us do it. After chewing on these facts for awhile, I am thinking that the best solution is for plpgsql to abandon the notion of a predetermined list of parameters for a SQL query altogether. What that list basically provides is a mapping from Param numbers ($n) to plpgsql datum numbers (indexes in the list of a plpgsql function's variables). We could make that mapping always be one-to-one, since there's no real reason that the Params available to a query have to be consecutively numbered. So the transformColumnRef hook would just pass back a Param using the referenced variable's datum number as paramid; it wouldn't bother at all with building a data structure listing the specific variables actually used in the query. As far as plancache goes, it would therefore always see a null array of Param type OIDs associated with a plpgsql-generated query, and we'd not have to provide a way to update that. (We'd still keep the ability to store such an array, because most other callers of plancache will still want a fixed list of Params.) What we'd have to add to plancache instead is the ability to install caller-determined parser callback hooks when it is calling the parser for a replan. This seems fairly easy to do --- I'm envisioning a sort of meta-hook function that gets called with the new ParseState and can insert hook function pointers in it. The other issue with this is what to do at runtime. We could do it with no other changes if we had plpgsql always set up Values/Nulls arrays listing *every* datum's current value. This seems a bit brute-force though --- it could be slow in a function with a lot of variables, and in most cases any specific query or expression would not need most of those values. What I think we should do instead is extend the ParamListInfo structure to add a callback hook function that populates individual ParamExternData array entries on-demand. The core executor would call the hook when it tried to fetch the value of a Param that was currently invalid (ptype == 0). So the hook would be invoked only once per query per referenced parameter, which shouldn't be much overhead. Another interesting property of this approach is that it'd fix the longstanding user complaint that constructions like if (TG_OP = 'INSERT' and NEW.foo = 'bar') ... fail prematurely. The executor would never demand the value of NEW.foo, and thus not fail, if TG_OP isn't INSERT. Comments? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Some notes about Param handling with Oracle style plpgsql variables
Pavel Stehule pavel.steh...@gmail.com writes: 2009/11/2 Tom Lane t...@sss.pgh.pa.us: This kinda calls into question whether the Oracle way is actually a good idea or not; but my purpose here is not to debate that, just to look at what it takes to implement it. This is reason, why I would to see third mode (incompatible with Oracle or pg), that raise error, when it detects any intersecting identifiers. I understand so this mode should not be default, but personally I'll use it everywhere. Actually, I thought we'd decided that throw error on conflict *would* be the default behavior. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Some notes about Param handling with Oracle style plpgsql variables
2009/11/2 Tom Lane t...@sss.pgh.pa.us: Pavel Stehule pavel.steh...@gmail.com writes: 2009/11/2 Tom Lane t...@sss.pgh.pa.us: This kinda calls into question whether the Oracle way is actually a good idea or not; but my purpose here is not to debate that, just to look at what it takes to implement it. This is reason, why I would to see third mode (incompatible with Oracle or pg), that raise error, when it detects any intersecting identifiers. I understand so this mode should not be default, but personally I'll use it everywhere. Actually, I thought we'd decided that throw error on conflict *would* be the default behavior. good regards Pavel regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Renaming conversion procs (was Re: [GENERAL] Error on compile for Windows)
Magnus Hagander mag...@hagander.net writes: On Mon, Nov 2, 2009 at 18:54, Tom Lane t...@sss.pgh.pa.us wrote: [ rename some conversion libraries to shorten source path names ] Seems like this would be a major PITA for packagers and end-user. If we actually wanted to back-patch it, I think the least painful way would be to tweak the Makefiles to install the built .so's under the old names in existing release branches. Then it would be a PITA only to the developers ;-). I don't personally feel it's worth it, even so. There are not that many people trying to build from source with weird tools. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Some notes about Param handling with Oracle style plpgsql variables
Robert Haas robertmh...@gmail.com writes: On Mon, Nov 2, 2009 at 11:31 AM, Tom Lane t...@sss.pgh.pa.us wrote: Another interesting property of this approach is that it'd fix the longstanding user complaint that constructions like if (TG_OP = 'INSERT' and NEW.foo = 'bar') ... fail prematurely. The executor would never demand the value of NEW.foo, and thus not fail, if TG_OP isn't INSERT. I don't really know enough to comment on the best way to go about this project overall, but fixing this would be incredibly nice, if it can be done without too much damage. After further reflection, there's a little more here than meets the eye. We can make it work as above for constructs that execute indivisibly from the point of view of a plpgsql function, like simple expressions. But there are also time-extended executions, like cursors and FOR-loop queries. What happens if you do something like declare x int; ... for r in select * from tab where id = x loop ... and change x inside the loop? Currently the code guarantees that these queries are run using the values that plpgsql variables had at the opening of the cursor or start of the for-loop. I think it would be a really bad idea to let it behave any differently --- even if it were rational to do something different, can you imagine trying to find bugs caused by such a change in functions that used to work? But that means we have to evaluate and copy the values of all variables that such a query *could* reference, even if it then fails to touch them at runtime. This doesn't seem like a fatal objection to me, but it's worth mentioning that the improvement will only apply in some contexts. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] per-tablespace random_page_cost/seq_page_cost
Hi, excuse the quoting style... and the intrepid nature of the following content... -- dim Le 1 nov. 2009 à 13:43, Greg Stark gsst...@mit.edu a écrit : We could have a column for all booleans, a column for all integers, etc. but that's not really any more normalized than having a single column for all the types with a rule for how to marshal each value type. Thé other day, on IRC, someone wanted a dynamic table accepting value in whichever column you name. That would probably mean having a special INSERT INTO which ALTER TABLE ... ADD COLUMN ... for you. Maybe INSERT INTO ... WITH ADD COLUMN OPTION; This sure looks suspicious, but the asking came from another product and it seems that could help here too. Oh and you get text columns I guess, by default... -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] per-tablespace random_page_cost/seq_page_cost
Dimitri Fontaine escribió: Thé other day, on IRC, someone wanted a dynamic table accepting value in whichever column you name. That would probably mean having a special INSERT INTO which ALTER TABLE ... ADD COLUMN ... for you. That sounds more like something you'd do with hstore or something similar. Didn't they also want an option to create the table on insert if it doesn't exist? -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] per-tablespace random_page_cost/seq_page_cost
On Mon, Nov 2, 2009 at 4:11 PM, Dimitri Fontaine dfonta...@hi-media.com wrote: Hi, excuse the quoting style... and the intrepid nature of the following content... -- dim Le 1 nov. 2009 à 13:43, Greg Stark gsst...@mit.edu a écrit : We could have a column for all booleans, a column for all integers, etc. but that's not really any more normalized than having a single column for all the types with a rule for how to marshal each value type. Thé other day, on IRC, someone wanted a dynamic table accepting value in whichever column you name. That would probably mean having a special INSERT INTO which ALTER TABLE ... ADD COLUMN ... for you. Maybe INSERT INTO ... WITH ADD COLUMN OPTION; This sure looks suspicious, but the asking came from another product and it seems that could help here too. Oh and you get text columns I guess, by default... If you want to start a discussion about a topic that is completely unrelated to this one, then please start a new thread. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] per-tablespace random_page_cost/seq_page_cost
On Mon, Nov 2, 2009 at 12:40 PM, Alvaro Herrera alvhe...@commandprompt.com wrote: Robert Haas escribió: I don't see anything in this code that is very rel-specific, so I think it would be possible to implement spcoptions by just defining RELOPT_KIND_TABLESPACE and ignoring the irony, but that has enough of an unsavory feeling that I'm sure someone is going to complain about it... I suppose we could go through and systematically rename all instances of reloptions to ent(ity)options or storageoptions or gen(eric)options or somesuch... Maybe I missed part of the discussion, but do these really need to be handled like reloptions instead of like datoptions? Perhaps the deciding factor is that we want to parse them once and store them in a cache, so like reloptions; the others are used once per connection and then thrown away. This may be a stupid question, but what are datoptions? $ git grep datoptions $ If this is the case, then I think we could just decide that their name is reloptions due to hysterical reasons and be done with it. Yeah. It's particularly unfortunate that we call them reloptions in the code but storage parameters in the documentation. Neither is a particularly good name, and having two different ones is extra-poor. But I'm fine with leaving the names as they are and moving on, if no one objects too much. Speak now or don't complain about it after I write the patch! ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] A small bug in gram.y
Hmmm no-one else feels this as a bug
The logic is that a function call is made for similar and the position
where SIMILAR occurs is at the third position, but it has been coded that it
is at fifth position.
Thanks,
Gokul.
On Tue, Oct 27, 2009 at 6:51 AM, Gokulakannan Somasundaram
gokul...@gmail.com wrote:
Hi,
In the gram.y, under a_expr rule
under the subrule a_expr NOT SIMILAR TO a_expr%prec
SIMILAR
the action is as follows
{
FuncCall *n = makeNode(FuncCall);
n-funcname = SystemFuncName(similar_escape);
n-args = list_make2($5, makeNullAConst(-1));
n-agg_star = FALSE;
n-agg_distinct = FALSE;
n-func_variadic = FALSE;
n-over = NULL;
n-location = @5;
$$ = (Node *) makeSimpleA_Expr(AEXPR_OP, !~, $1,
(Node *) n, @2);
}
I think the n-location should be @3.
Thanks,
Gokul.
Re: [HACKERS] A small bug in gram.y
Gokulakannan Somasundaram wrote: Hmmm no-one else feels this as a bug The logic is that a function call is made for similar and the position where SIMILAR occurs is at the third position, but it has been coded that it is at fifth position. The function call is constructed for the similar_escape function, to construct a regular expression equivalent to the right operand of the SIMILAR TO. So setting the error location to the right operand seems OK to me. However, I note that for the a_expr SIMILAR TO a_expr rule we're doing what you expected and the error location points to SIMILAR. I think we should change that to behave like NOT SIMILAR TO. Here's an example that exercises those paths: postgres=# SELECT 'aa' NOT SIMILAR TO 123; ERROR: function pg_catalog.similar_escape(integer, unknown) does not exist LINE 1: SELECT 'aa' NOT SIMILAR TO 123; ^ HINT: No function matches the given name and argument types. You might need to add explicit type casts. postgres=# SELECT 'aa' SIMILAR TO 123; ERROR: function pg_catalog.similar_escape(integer, unknown) does not exist LINE 1: SELECT 'aa' SIMILAR TO 123; ^ HINT: No function matches the given name and argument types. You might need to add explicit type casts. postgres=# I think the former error location is better. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
