On Tue, Oct 20, 2009 at 8:55 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Dave Page dp...@pgadmin.org writes:
I just realised there's a nasty problem with this. In my client
application, I can use PQconninfoParse to determine if
application_name (or fallback_application_name) are valid connection
Dave Page wrote:
On Tue, Oct 20, 2009 at 8:55 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Dave Page dp...@pgadmin.org writes:
I just realised there's a nasty problem with this. In my client
application, I can use PQconninfoParse to determine if
application_name (or fallback_application_name) are
On Wed, 2009-10-14 at 18:44 +0200, Magnus Hagander wrote:
On Wed, Oct 14, 2009 at 18:39, Dave Page dp...@pgadmin.org wrote:
On Wed, Oct 14, 2009 at 5:37 PM, Eric B. Ridge e...@tcdi.com wrote:
On Oct 13, 2009, at 11:02 AM, Dave Page wrote:
A useful feature found in other DBMSs such as MS
On Wed, Oct 21, 2009 at 10:14 AM, Simon Riggs si...@2ndquadrant.com wrote:
ISTM much of the complexity discussed relates to this second feature.
Let's just concentrate on getting the connection-pool-identification
aspect of this done right and then maybe add second part later.
That side of
On Wed, 2009-10-21 at 10:19 +0100, Dave Page wrote:
On Wed, Oct 21, 2009 at 10:14 AM, Simon Riggs si...@2ndquadrant.com wrote:
ISTM much of the complexity discussed relates to this second feature.
Let's just concentrate on getting the connection-pool-identification
aspect of this done
On Wed, Oct 21, 2009 at 10:40 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, 2009-10-21 at 10:19 +0100, Dave Page wrote:
On Wed, Oct 21, 2009 at 10:14 AM, Simon Riggs si...@2ndquadrant.com wrote:
ISTM much of the complexity discussed relates to this second feature.
Let's just
On Wed, Oct 21, 2009 at 10:14 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Looking at the way we process the startup packet in
ProcessStartupPacket, there's one dirty hack you could do. As the code
stands, if you specify options key/value pair more than once, the
latter
On Tue, 2009-10-20 at 20:48 -0400, Tom Lane wrote:
So I went to see about making the changes to remove regex_flavor, and
was astonished to find that all the regex-related functions are already
marked immutable, and AFAICS always have been. This is clearly wrong,
and we would have to fix it if
On Wed, 2009-10-21 at 13:11 +0900, Itagaki Takahiro wrote:
The attached patch replace BOM with while spaces, but it does not
change client encoding automatically. I think we can always ignore
client encoding at the replacement because SQL command cannot start
with BOM sequence. If we don't
On Wed, 2009-10-21 at 10:45 +0100, Dave Page wrote:
On Wed, Oct 21, 2009 at 10:40 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, 2009-10-21 at 10:19 +0100, Dave Page wrote:
On Wed, Oct 21, 2009 at 10:14 AM, Simon Riggs si...@2ndquadrant.com
wrote:
ISTM much of the complexity
On Wed, Oct 21, 2009 at 11:06 AM, Simon Riggs si...@2ndquadrant.com wrote:
The SET seems sufficient for me. All interfaces currently support it.
SET alone will not allow what I see as one of the most useful uses of
this - consider:
PGAPPLICATIONNAME=Nightly backup pg_dump mydb
Dave Page wrote:
On Wed, Oct 21, 2009 at 10:14 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Looking at the way we process the startup packet in
ProcessStartupPacket, there's one dirty hack you could do. As the code
stands, if you specify options key/value pair more than
On Wed, 2009-10-21 at 11:20 +0100, Dave Page wrote:
On Wed, Oct 21, 2009 at 11:06 AM, Simon Riggs si...@2ndquadrant.com wrote:
The SET seems sufficient for me. All interfaces currently support it.
SET alone will not allow what I see as one of the most useful uses of
this - consider:
On Wed, Oct 21, 2009 at 11:49, Dave Page dp...@pgadmin.org wrote:
Another idea is to do something similar to the 'prefer' SSL mode, or if
the server doesn't support protocol version 3: Try with the GUC in
startup packet first, and if that fails, retry without it.
I'm not sure if I like either
On Wed, Oct 21, 2009 at 12:45, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, 2009-10-21 at 11:20 +0100, Dave Page wrote:
On Wed, Oct 21, 2009 at 11:06 AM, Simon Riggs si...@2ndquadrant.com wrote:
The SET seems sufficient for me. All interfaces currently support it.
SET alone will not
On Wed, 2009-10-21 at 12:49 +0200, Magnus Hagander wrote:
PGOPTIONS is the way to do that, no? It can be a bit tricky when you
have to deal with quoting, but it is there and it works...
Which will work for application name also.
--
Simon Riggs www.2ndQuadrant.com
--
Sent via
On Wed, Oct 21, 2009 at 12:01 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, 2009-10-21 at 12:49 +0200, Magnus Hagander wrote:
PGOPTIONS is the way to do that, no? It can be a bit tricky when you
have to deal with quoting, but it is there and it works...
Which will work for application
Could someone clarify why this (from PG 8.4)
# \du
List of roles
Role name | Attributes | Member of
---+-+
admin | Create role | {}
: Create DB
postgres | Superuser | {}
: Create role
2009/10/21 Peter Eisentraut pete...@gmx.net:
Could someone clarify why this (from PG 8.4)
# \du
List of roles
Role name | Attributes | Member of
---+-+
admin | Create role | {}
: Create DB
postgres |
Peter Eisentraut wrote:
On Wed, 2009-10-21 at 13:11 +0900, Itagaki Takahiro wrote:
The attached patch replace BOM with while spaces, but it does not
change client encoding automatically. I think we can always ignore
client encoding at the replacement because SQL command cannot start
with
Peter Eisentraut pete...@gmx.net writes:
On Tue, 2009-10-20 at 20:48 -0400, Tom Lane wrote:
So I went to see about making the changes to remove regex_flavor, and
was astonished to find that all the regex-related functions are already
marked immutable, and AFAICS always have been. This is
Peter Eisentraut wrote:
Could someone clarify why this (from PG 8.4)
# \du
List of roles
Role name | Attributes | Member of
---+-+
admin | Create role | {}
: Create DB
postgres | Superuser | {}
Tom Lane t...@sss.pgh.pa.us wrote:
[ scratches head... ] I thought the JDBC spec already said exactly
how one would set this. Why would we go to significant effort to
make it behave contrary to spec?
We certainly should allow it to be set as specified in the spec. The
only question is
So, having dismissed my original off-the-cuff answer to Rod, the next
question is what's really going wrong for him. I get this from
a quick trial:
I wish I had kept specific notes on what I was actually trying to do.
I tried to_number first then the expression as seen below. I guess I
saw
Magnus Hagander wrote:
From a quick look, it looks fine to me. I don't have time to do a
complete check right now, but I'll do that as soon as I can and then
commit it - unless people feel it's more urgent than maybe a week
worst case, in which case someone else has to pick it up :-)
Are we
Rod Taylor rod.tay...@gmail.com writes:
It is interesting that citext seems to be functional with exactly
the same statements.
Huh, it looks to me like that's an error in the declaration of the
citext versions of regexp_matches --- they should be declared to return
setof text[], the same as the
Alvaro Herrera alvhe...@commandprompt.com writes:
Magnus Hagander wrote:
From a quick look, it looks fine to me. I don't have time to do a
complete check right now, but I'll do that as soon as I can and then
commit it - unless people feel it's more urgent than maybe a week
worst case, in
Andrew Chernow wrote:
I'll hack the makefile and give it a shot.
No need to hack it, set CFLAGS during configure:
shell]# CFLAGS=-m64 ./configure (options)
I tried that and it still built a 32 bit version of perl. When I
checked the make file it didn't have CFLAGS anywhere. I manually
Dave Page dp...@pgadmin.org writes:
Should we perhaps change the behaviour of the backend to give a
warning only for unknown settings in the startup packet?
It's not going to help, unless you first invent a time machine so
we can retroactively cause all PG servers that are already in the field
Alvaro Herrera alvhe...@commandprompt.com writes:
The reason it's an improvement of sorts is that there are now more
possible attributes, and if we had kept adding columns it would have
become wider than 80 columns.
Yeah, 8.4 has two more possible entries, and adding them as separate
columns
Kevin Grittner kevin.gritt...@wicourts.gov writes:
(or whatever name we choose for this in place of PGAPPNAME.)
FWIW, I would prefer PGAPPNAME to PGAPPLICATIONNAME which is what
Dave has been using in his examples. The latter is too frickin
long, and the double N is a typo threat (I already
Tom Lane wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
(or whatever name we choose for this in place of PGAPPNAME.)
FWIW, I would prefer PGAPPNAME to PGAPPLICATIONNAME which is what
Dave has been using in his examples. The latter is too frickin
long, and the double N is
Andrew Dunstan and...@dunslane.net writes:
Tom Lane wrote:
FWIW, I would prefer PGAPPNAME to PGAPPLICATIONNAME which is what
We don't usually use abbreviations, so how about PGCLIENTNAME or some such?
Not sure I believe that argument. Among the set of existing libpq
environment variables I
On Wed, Oct 21, 2009 at 11:25 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net writes:
Tom Lane wrote:
FWIW, I would prefer PGAPPNAME to PGAPPLICATIONNAME which is what
We don't usually use abbreviations, so how about PGCLIENTNAME or some such?
Not sure I believe
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
Tom Lane wrote:
FWIW, I would prefer PGAPPNAME to PGAPPLICATIONNAME which is what
We don't usually use abbreviations, so how about PGCLIENTNAME or some such?
Not sure I believe that argument. Among the
Hi,
I'm writing two functions parse_url_key and parse_url_record which
will have one text argument and will return a record or a specific
column of it. Theses functions are calling parse_url_exec which parse
the URL. When theses function will works, i'll purpose them to
PostgreSQL community.
The
On Wed, Oct 21, 2009 at 3:49 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Dave Page dp...@pgadmin.org writes:
Should we perhaps change the behaviour of the backend to give a
warning only for unknown settings in the startup packet?
It's not going to help, unless you first invent a time machine so
On Wed, Oct 21, 2009 at 4:29 PM, Robert Haas robertmh...@gmail.com wrote:
I also like PGAPPNAME better, for the same reasons as Tom.
:-). Have to admit, I've mistyped it a few times too.
--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
PGDay.EU 2009 Conference:
Samuel ROZE samuel.r...@gmail.com writes:
The problem is that they don't work fine... :/
I think the problem is that you are passing C strings to code that
expects pointers to text datums --- which are not the same thing
at all. (text has a length word, not a null terminator byte.)
It's pure
On Wed, Oct 21, 2009 at 4:39 PM, Dave Page dp...@pgadmin.org wrote:
On Wed, Oct 21, 2009 at 3:49 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Dave Page dp...@pgadmin.org writes:
This might be a good argument for changing that going forward, but
it will be *years* before we can rely on it for
Samuel ROZE wrote:
PG_FUNCTION_INFO_V1(parse_url_record);
Datum parse_url_record (PG_FUNCTION_ARGS)
{
// Vars about the params
//text *str2 = PG_GETARG_TEXT_P(0);
char str[] = http://www.ovh.com/intenal.html;;
// Some vars which will used to create the composite
Thanks for your reply.
PG_FUNCTION_INFO_V1(parse_url_record);
Datum parse_url_record (PG_FUNCTION_ARGS)
{
// Vars about the params
//text *str2 = PG_GETARG_TEXT_P(0);
char str[] = http://www.ovh.com/intenal.html;;
Dave Page dp...@pgadmin.org wrote:
Robert Haas robertmh...@gmail.com wrote:
I also like PGAPPNAME better, for the same reasons as Tom.
:-). Have to admit, I've mistyped it a few times too.
Well, it would seem we have consensus on that. :-)
I don't feel that the Java default issue
Le mercredi 21 octobre 2009 à 11:42 -0400, Tom Lane a écrit :
CStringGetTextDatum
Can you give me more precisions ?
I'm creating a user C function, with shared library and
CStringGetTextDatum is in varlena.h file which is not in the
src/include dir... How can I include it ?
Thanks.
Samuel.
On Oct 21, 2009, at 7:27 AM, Tom Lane wrote:
Huh, it looks to me like that's an error in the declaration of the
citext versions of regexp_matches --- they should be declared to
return
setof text[], the same as the underlying text functions. David, do
you
agree?
Ooh, yeah, dunno how I
Dave Page dp...@pgadmin.org writes:
BTW, any thoughts on Heikki's suggestions of hacking about the
'options' value or retrying the connection vs. just doing a SET
post-connection in libpq? It's pretty certain that whatever I choose
you probably won't like :-p
The post-connect SET still seems
Samuel ROZE wrote:
Le mercredi 21 octobre 2009 à 11:42 -0400, Tom Lane a écrit :
CStringGetTextDatum
Can you give me more precisions ?
I'm creating a user C function, with shared library and
CStringGetTextDatum is in varlena.h file which is not in the
src/include dir... How can I
David E. Wheeler da...@kineticode.com writes:
On Oct 21, 2009, at 7:27 AM, Tom Lane wrote:
Huh, it looks to me like that's an error in the declaration of the
citext versions of regexp_matches --- they should be declared to
return
setof text[], the same as the underlying text functions.
The Hot Standby patch changes lock_twophase_recover() so that when we're
starting up from Hot Standby mode to normal operation, as opposed to
crash recovery, we assume that all AccessExcusiveLocks are already held
by the startup process and instead of acquiring them anew they are
transferred from
I've done it but I had no results... strange.
I've a 8.3 version and this lines are NOT in the file:
00668 /* varlena.c */
00669 extern text *cstring_to_text(const char *s);
00670 extern text *cstring_to_text_with_len(const char *s, int len);
00671 extern char *text_to_cstring(const text *t);
On Oct 21, 2009, at 9:37 AM, Tom Lane wrote:
Ooh, yeah, dunno how I missed that.
I think we're probably stuck in 8.4, but we should fix it going
forward. Would you make a quick check if any of the other citext
functions have the same bug?
I've fixed it in my [version for
On Oct 21, 2009, at 9:40 AM, David E. Wheeler wrote:
On Oct 21, 2009, at 9:37 AM, Tom Lane wrote:
Ooh, yeah, dunno how I missed that.
I think we're probably stuck in 8.4, but we should fix it going
forward. Would you make a quick check if any of the other citext
functions have the same
David E. Wheeler da...@kineticode.com writes:
FWIW, I think that this is a bug, and that the variation from the text
version will be unexpected. I recommend fixing it for 8.4.2.
Well, it's certainly a bug, but I don't think it's back-patchable.
A back-patch will not affect existing
I'm now using C strings. I don't need to use CStringGetTextDatum, but it
still don't works. There's the code:
---
PG_FUNCTION_INFO_V1(parse_url_record);
Datum parse_url_record (PG_FUNCTION_ARGS)
{
// Vars about the params
David E. Wheeler da...@kineticode.com writes:
Is there a straight-foward way to check such a thing
programmatically, with a query perhaps? Or should I just put aside an
hour to do an audit?
I was wondering whether you could query pg_proc to look for functions
with the same name and
Samuel ROZE samuel.r...@gmail.com writes:
I've done it but I had no results... strange.
I've a 8.3 version and this lines are NOT in the file:
Oh, it was changed in 8.4 IIRC. If you are thinking of submitting
code to the project you should not be developing against a back
release anyway ...
On Oct 21, 2009, at 9:48 AM, Tom Lane wrote:
I was wondering whether you could query pg_proc to look for functions
with the same name and different arguments/results. It's a bit tricky
though because you'd expect s/citext/text/ in at least some positions
(maybe not all)?
Yeah, almost all.
Samuel ROZE wrote:
I've done it but I had no results... strange.
I've a 8.3 version and this lines are NOT in the file:
You neglected to tell us you were in 8.3 before, I think.
On 8.3 you might need to put a #define for it directly in your C file.
cheers
andrew
--
Sent via
On Wed, 2009-10-21 at 19:37 +0300, Heikki Linnakangas wrote:
So, I'm quite eager to just revert all those lock_twophase_recover()
changes, and always rely on the grant lock to dummy proc, then
release
it in startup process method. If we don't want to rely on that,
PostPrepare_Locks is an
Le mercredi 21 octobre 2009 à 12:59 -0400, Andrew Dunstan a écrit :
On 8.3 you might need to put a #define for it directly in your C file.
I can't: cstring_to_text isn't defined.
I'll develop on 8.4.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
Samuel ROZE wrote:
Le mercredi 21 octobre 2009 à 12:59 -0400, Andrew Dunstan a écrit :
On 8.3 you might need to put a #define for it directly in your C file.
I can't: cstring_to_text isn't defined.
I'll develop on 8.4.
or try:
#define CStringGetTextP(c)
Here's what I'm thinking of doing to enable plpgsql to resolve variable
references during the main SQL parser processing, instead of its current
hack of replacing references with $n in advance:
1. Add some fields to ParseState to carry hook function pointers as
well as void * passthrough
Tom Lane wrote:
That options hack was just an ugly hack, I don't like it at all ---
mainly because I don't believe that approach scales to solve more
than one case either.
It does if you hack it even more: don't pass the (first) options
directly as command line arguments, but parse it in
Tom,
1. Invent a GUC that has the settings backwards-compatible,
oracle-compatible, throw-error (exact spellings TBD). Factory default,
at least for a few releases, will be throw-error. Make it SUSET so that
unprivileged users can't break things by twiddling it; but it's still
possible for
On Wed, Oct 21, 2009 at 12:27 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Dave Page dp...@pgadmin.org writes:
BTW, any thoughts on Heikki's suggestions of hacking about the
'options' value or retrying the connection vs. just doing a SET
post-connection in libpq? It's pretty certain that whatever I
On Wed, Oct 21, 2009 at 1:59 PM, Josh Berkus j...@agliodbs.com wrote:
Tom,
1. Invent a GUC that has the settings backwards-compatible,
oracle-compatible, throw-error (exact spellings TBD). Factory default,
at least for a few releases, will be throw-error. Make it SUSET so that
unprivileged
Robert Haas robertmh...@gmail.com writes:
On Wed, Oct 21, 2009 at 12:27 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The post-connect SET still seems like the best choice to me.
Are we really thinking about interposing an additional server
round-trip on every connection for such a marginal feature
On Wed, Oct 21, 2009 at 2:41 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Oct 21, 2009 at 12:27 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The post-connect SET still seems like the best choice to me.
Are we really thinking about interposing an
On Oct 21, 2009, at 11:37 AM, Robert Haas wrote:
That's like saying that it's less of a risk than a group of rabid
tyrannosaurs in a kindergarten classroom.
I'm not sure, but I kind of doubt that tyrannosaurs can get rabies. I
mean, if they were even around anymore. Which, you know, they're
Robert Haas robertmh...@gmail.com writes:
On Wed, Oct 21, 2009 at 2:41 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Only connections that are actually using the feature. It doesn't
bother me that much --- before 7.4 we had *multiple* round trips
involved in a connection start,
OK, but surely
Robert,
H. I don't see any reason why this couldn't be set by any user at
runtime, really. From a security standpoint, it's less of a risk than
search_path, and we allow anyone to mess with that.
That's like saying that it's less of a risk than a group of rabid
tyrannosaurs in a
Josh Berkus j...@agliodbs.com writes:
Making this GUC suset would make it far less useful to users trying to
gradually upgrade their infrastructures, and make it more likely that
many/most of our users would just set it to backwards-compatible in
their postgresql.conf and not fix anything. In
That's what the #option alternative is for. Yes, it's a bit ugly, but
it's perfectly functional, and secure too.
I still don't see why it's needed. If the function owner simply sets
the option in the function definitions (as a userset), it doesn't matter
what the calling user sets, does it?
Simon Riggs wrote:
On Wed, 2009-10-21 at 19:37 +0300, Heikki Linnakangas wrote:
So, I'm quite eager to just revert all those lock_twophase_recover()
changes, and always rely on the grant lock to dummy proc, then
release
it in startup process method. If we don't want to rely on that,
On 10/21/09 1:02 PM, Josh Berkus wrote:
That's what the #option alternative is for. Yes, it's a bit ugly, but
it's perfectly functional, and secure too.
I still don't see why it's needed. If the function owner simply sets
the option in the function definitions (as a userset), it doesn't
It is solved. I'll propose my work the next weeks. :-)
Regards,
Samuel.
Le mercredi 21 octobre 2009 à 17:31 +0200, Samuel ROZE a écrit :
Hi,
I'm writing two functions parse_url_key and parse_url_record which
will have one text argument and will return a record or a specific
column of it.
Alpha2 has been bundled and is available at
http://developer.postgresql.org/~petere/alpha/
Please check that it is sane.
Then, someone please move this to an appropriate place on the FTP server
and make an announcement. Josh Berkus is coordinating the announcement.
See
On Wed, Oct 21, 2009 at 3:09 PM, Josh Berkus j...@agliodbs.com wrote:
Tom has proposed some kind of odd special options syntax to get around
this, but I think that's unnecessary. So far on this thread, I haven't
seen anyone engineer an actual function exploit by using this setting; I
On Wed, 2009-10-21 at 23:02 +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
On Wed, 2009-10-21 at 19:37 +0300, Heikki Linnakangas wrote:
So, I'm quite eager to just revert all those lock_twophase_recover()
changes, and always rely on the grant lock to dummy proc, then
release
it
On Wed, Oct 21, 2009 at 4:28 PM, Merlin Moncure mmonc...@gmail.com wrote:
On Wed, Oct 21, 2009 at 3:09 PM, Josh Berkus j...@agliodbs.com wrote:
Tom has proposed some kind of odd special options syntax to get around
this, but I think that's unnecessary. So far on this thread, I haven't
seen
Can't find it ... and it doesn't look like anyone has moved it ...
On Wed, 21 Oct 2009, Peter Eisentraut wrote:
Alpha2 has been bundled and is available at
http://developer.postgresql.org/~petere/alpha/
Please check that it is sane.
Then, someone please move this to an appropriate place on
Robert Haas robertmh...@gmail.com writes:
I actually think that we should not have a GUC for this at all. We
should have a compiled-in default, and it should be error. If you
want some other behavior, decorate your functions with #option.
We've agreed that the factory default should be
Josh Berkus j...@agliodbs.com writes:
That's what the #option alternative is for. Yes, it's a bit ugly, but
it's perfectly functional, and secure too.
I still don't see why it's needed. If the function owner simply sets
the option in the function definitions (as a userset), it doesn't
On Wed, Oct 21, 2009 at 5:02 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I actually think that we should not have a GUC for this at all. We
should have a compiled-in default, and it should be error. If you
want some other behavior, decorate your functions
Tom Lane t...@sss.pgh.pa.us wrote:
3. The pre-transform hook would have a signature like
Node *hook(ParseState *pstate, ColumnRef *cref)
4. The post-transform hook would have a signature like
Node *hook(ParseState *pstate, ColumnRef *cref, Node *var)
Are there any
2009/10/21 Tom Lane t...@sss.pgh.pa.us:
Josh Berkus j...@agliodbs.com writes:
Making this GUC suset would make it far less useful to users trying to
gradually upgrade their infrastructures, and make it more likely that
many/most of our users would just set it to backwards-compatible in
their
2009/10/22 Itagaki Takahiro itagaki.takah...@oss.ntt.co.jp:
Tom Lane t...@sss.pgh.pa.us wrote:
3. The pre-transform hook would have a signature like
Node *hook(ParseState *pstate, ColumnRef *cref)
4. The post-transform hook would have a signature like
Node *hook(ParseState
Simon Riggs wrote:
On Wed, 2009-10-21 at 23:02 +0300, Heikki Linnakangas wrote:
Hmm, dunno about that, but there is one problem with the grant to dummy
proc, then release in startup process approach. What if there isn't
enough shared memory available to re-acquire the lock for the dummy
proc?
88 matches
Mail list logo
