Re: [HACKERS] psql \d option list overloaded
Am Sonntag, 4. Januar 2004 20:13 schrieb Alex J. Avriette: On Sat, Jan 03, 2004 at 08:25:21PM -0500, Bruce Momjian wrote: I finally figure it out, I just end up forgetting again later. I still ... /functions /databases ... Long options sounds really good. It is like GNU-tools. A single - for single character options and a double -- for long options. Ah - a single \ for short options in postgresql and a double \\ for long? What do you think? -- Dr. Eckhardt + Partner GmbH http://www.epgmbh.de ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] TODO list
Bruce Momjian said: Andrew Dunstan wrote: 2 things. I submitted a patch for this 5 months ago, which is still waiting to be merged (hope it hasn't bitrotted in the meantime): . Allow log lines to include session-level information, like database and user If nobody is working on this I am prepared to look at it: . Allow logging of only data definition(DDL), or DDL and modification statements Yes, sorry I haven't gotten back to that, and yes the DDL idea is a good one. For the log idea, I think we need to get a way to merge all the per-line info into one setup, so pid, timestamp, user, etc would all be configurable using your setup. I thought we had thrashed this out back in August. Certainly the only thing I recall seeing after I submitted the patch was some stylistic criticism from Neil, which I addressed in a revised patch. Anyway, it is in principle doable. That's partly why I adopted a printf style format string. There are some wrinkles, though: . interaction with syslog pid/timestamp logging . making sure the info is available when you need to log it - I had to rearrange a few thing to avoid getting SEGVs, IIRC. Also, the session duration logging part of the patch is orthogonal to the issue. cheers andrew ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Announce: Search PostgreSQL related resources
http://www.pgsql.ru/ We are welcome your feedback and comments. Very nice work! I've just found some docs I was looking for a long time :) Bye, Chris. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Anything akin to an Evaluate Statement in Postgresql?
Tomand Chris, I tried to use a for in loop to execute the statement to try to get some dynamic functionality but I get "ERROR: missing ".." at end of SQL _expression_" what am I doing wrong? Code: qry := ''select * from ''|| trim(realname) ||'' where ''|| trim(searchfield) ||'' like %''|| trim(searchvalue) ||''%'';arrayval := string_to_array(coltoparammatch(3, talias, insertparams, insertdelimiter), '','');for objectdefinition in execute qry loopfor i in array_lower(arrayval, 1)..array_upper(arrayval, 1) loop qry := ''select objectdefinition.''|| arrayval[i]; for aliasvalue in execute qry loop RAISE NOTICE ''field = %'', aliasvalue; end loop;end loop;end loop; So that everyone realizes what I am trying to do. I execute a function coltoparammatch to return a string list of field names in a given table. I am then executing a query to get a reference to the table I want to pull data from. I then loop in the array of column names and "try" to make a dynamic column reference to the recordset that the query is being held in. Alas no luck though. TIA AlexTom Lane [EMAIL PROTECTED] wrote: A E <[EMAIL PROTECTED]>writes: I tried to execute a dynamic sql string using the dynamic record column name but I getting this error: ERROR: syntax error at or near "into" at character 8. Does the execute statement not allow the into keywordIt does not :-(. The best way of getting data back from an EXECUTE'dselect is to use a FOR ... IN EXECUTE loop. See the docs.regards, tom lane---(end of broadcast)---TIP 6: Have you searched our list archives?http://archives.postgresql.org
Re: [HACKERS] Anything akin to an Evaluate Statement in Postgresql?
A E [EMAIL PROTECTED] writes: I tried to use a for in loop to execute the statement to try to get some dynamic functionality but I get ERROR: missing .. at end of SQL expression what am I doing wrong? Did you declare the loop variable (here, objectdefinition) as a record or rowtype variable? If the loop variable is not known, plpgsql assumes this is a locally-declared-integer kind of FOR loop, which leads it to expect the lowbound .. highbound kind of syntax, which leads to the above error message. regards, tom lane ---(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] Anything akin to an Evaluate Statement in Postgresql?
objectdefinition is defined as a record variable. It works fine when I remove the statement trying to get the dynamically concocted stringexecuted and the results placed into the aliasvalue variable which is varchar. My first questionis, Can you perform a select on a variable? Such as in the case of executing the dynamic string of objectdefinition.[Whatever Value] My next question is do you have declare the variable beingused in a for in execute as a record variable? If so is this by design orlimitation? My last question is has anyone else run into this before? Where the name of the column was unknown, and it was dynamically generated and needed to be turned into a referenceinstead of a string? TIA AlexTom Lane [EMAIL PROTECTED] wrote: A E <[EMAIL PROTECTED]>writes: I tried to use a for in loop to execute the statement to try to get some dynamic functionality but I get "ERROR: missing ".." at end of SQL _expression_" what am I doing wrong?Did you declare the loop variable (here, "objectdefinition") as arecord or rowtype variable? If the loop variable is not known,plpgsql assumes this is a locally-declared-integer kind of FOR loop,which leads it to expect the lowbound .. highbound kind of syntax,which leads to the above error message.regards, tom lane
Re: [HACKERS] TODO list
Andrew Dunstan wrote:
Bruce Momjian said:
Andrew Dunstan wrote:
2 things.
I submitted a patch for this 5 months ago, which is still waiting to
be merged (hope it hasn't bitrotted in the meantime):
. Allow log lines to include session-level information, like database
and user
If nobody is working on this I am prepared to look at it:
. Allow logging of only data definition(DDL), or DDL and modification
statements
Yes, sorry I haven't gotten back to that, and yes the DDL idea is a good
one.
For the log idea, I think we need to get a way to merge all the
per-line info into one setup, so pid, timestamp, user, etc would all be
configurable using your setup.
I thought we had thrashed this out back in August. Certainly the only
thing I recall seeing after I submitted the patch was some stylistic
criticism from Neil, which I addressed in a revised patch.
Anyway, it is in principle doable. That's partly why I adopted a printf
style format string. There are some wrinkles, though:
. interaction with syslog pid/timestamp logging
Yes. If you use syslog, just don't ask for pid/timestamp and let syslog
do it. Of course, right now we are able to send non-pid/timestamp to
syslog _and_ send pid/timestamp to a log file, but that seems like a
rare operation that doesn't justify keeping the various log parameters
separate.
Also, I would like to see some kind of session identifier that is more
unique than pid, which wraps around. Ideally we could have 10{pid},
then then the pid wraps around, 20{pid), or something like that.
. making sure the info is available when you need to log it - I had to
rearrange a few thing to avoid getting SEGVs, IIRC.
Of course some messages, like postmaster status messages, don't have
some of these fields, like username or host. Is that going to cause
problems for tools that read our log files?
Also, the session duration logging part of the patch is orthogonal to the
issue.
You mean query duration? Yes, it is orthoginal.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] [PATCHES] remove 'noversion' from standalone backend
(To hackers) On Tue, Jan 06, 2004 at 01:06:17PM -0500, Neil Conway wrote: P.S. BTW, how does everyone feel about the methodology I've been using for submitting and applying patches? The procedure I'm following is: The only thing I'd like is that the applied patch is attached in the automatic mail sent to pgsql-committers (or if people want to keep that as a light traffic list, maybe another list could be created). This way we could all easily see what's applied, as a whole, and learn from it. This is not so much for your own patches because you also post them to patches and that is enough for me, but for Tom's and other people's patches. IIRC somebody offered to do this not long ago ... -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) I think my standards have lowered enough that now I think 'good design' is when the page doesn't irritate the living f*ck out of me. (JWZ) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] TODO list
Bruce Momjian wrote:
Andrew Dunstan wrote:
I thought we had thrashed this out back in August. Certainly the only
thing I recall seeing after I submitted the patch was some stylistic
criticism from Neil, which I addressed in a revised patch.
Anyway, it is in principle doable. That's partly why I adopted a printf
style format string. There are some wrinkles, though:
. interaction with syslog pid/timestamp logging
Yes. If you use syslog, just don't ask for pid/timestamp and let syslog
do it. Of course, right now we are able to send non-pid/timestamp to
syslog _and_ send pid/timestamp to a log file, but that seems like a
rare operation that doesn't justify keeping the various log parameters
separate.
I'm OK with that as long as it is the consensus view. It does seem a
little odd to remove functionality (however rare) for the sake of
configuration neatness, though.
Also, I would like to see some kind of session identifier that is more
unique than pid, which wraps around. Ideally we could have 10{pid},
then then the pid wraps around, 20{pid), or something like that.
This requires some thought. ISTM it wouldn't buy you much unless you
made it persistent across server restarts, and possibly not even then. I
don't see it as a reason to hold up these features, though. If someone
wants to tackle this it could be plugged in to the loginfo feature very
easily as an extra escape sequence.
. making sure the info is available when you need to log it - I had to
rearrange a few thing to avoid getting SEGVs, IIRC.
Of course some messages, like postmaster status messages, don't have
some of these fields, like username or host. Is that going to cause
problems for tools that read our log files?
If users want a non-empty info string they will have to teach the tools
to handle it anyway. The point was, however, that rolling up PID and
timestamp into the printf-style format will require some significant
work, because we wouldn't want to lose that info if the user/db weren't
known, whereas the patch currently suppresses all log-info output if
these are not present (i.e. when MyProcPort == NULL).
Also, the session duration logging part of the patch is orthogonal to the
issue.
You mean query duration? Yes, it is orthoginal.
No, I meant the logging of the end of a session, including its duration,
which was also in the patch.
cheers
andrew
---(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
[HACKERS] Reserved words and named function parameters
I've been reviewing Dennis Bjorklund's patch to support named function parameters: http://archives.postgresql.org/pgsql-patches/2003-12/msg00176.php One thing I didn't like about it was that the grammar declared param_name as plain IDENT, meaning that you could not use even unreserved keywords as param names. One would prefer ColId, but naturally that causes a truckload of shift and reduce conflicts :-( After some fooling around I find that these combinations work: 1. Make param_name equate to type_name (allowing IDENT or unreserved_keyword), and move the following keywords from unreserved to col_name_keyword status: DOUBLE INOUT NATIONAL OUT 2. Make param_name equate to function_name (allowing IDENT, unreserved_keyword, or func_name_keyword). This requires the above changes plus moving IN from func_name_keyword to fully reserved status. Any opinions which to do, or alternate proposals? I'm leaning slightly to #2, since I doubt anyone is trying to use IN as a function name, but ... regards, tom lane ---(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] Proposed Query Planner TODO items
Tom, I've made some progress on this over the last week or two. Would it be possible to retry that benchmark with CVS tip? Yes! I'll just need some time to get my laptop set up for running it. My server is, alas, in storage due to me being between offices. -- -Josh Berkus Aglio Database Solutions San Francisco ---(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] Reserved words and named function parameters
Tom Lane wrote: I've been reviewing Dennis Bjorklund's patch to support named function parameters: http://archives.postgresql.org/pgsql-patches/2003-12/msg00176.php One thing I didn't like about it was that the grammar declared param_name as plain IDENT, meaning that you could not use even unreserved keywords as param names. One would prefer ColId, but naturally that causes a truckload of shift and reduce conflicts :-( After some fooling around I find that these combinations work: 1. Make param_name equate to type_name (allowing IDENT or unreserved_keyword), and move the following keywords from unreserved to col_name_keyword status: DOUBLE INOUT NATIONAL OUT 2. Make param_name equate to function_name (allowing IDENT, unreserved_keyword, or func_name_keyword). This requires the above changes plus moving IN from func_name_keyword to fully reserved status. Any opinions which to do, or alternate proposals? I'm leaning slightly to #2, since I doubt anyone is trying to use IN as a function name, but ... I support #2 rather more strongly ;-) cheers andrew ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] TODO list
On Tue, 6 Jan 2004, Andrew Dunstan wrote:
Also, I would like to see some kind of session identifier that is more
unique than pid, which wraps around. Ideally we could have 10{pid},
then then the pid wraps around, 20{pid), or something like that.
This requires some thought. ISTM it wouldn't buy you much unless you
made it persistent across server restarts, and possibly not even then.
And on OpenBSD (though no other platforms that I know of) the PID is a
random number, so there is no wrapping to begin with.
Jon
---(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] TODO list
Am Tuesday 06 January 2004 21:30 schrieb Jon Jensen:
On Tue, 6 Jan 2004, Andrew Dunstan wrote:
Also, I would like to see some kind of session identifier that is more
unique than pid, which wraps around. Ideally we could have 10{pid},
then then the pid wraps around, 20{pid), or something like that.
This requires some thought. ISTM it wouldn't buy you much unless you
made it persistent across server restarts, and possibly not even then.
And on OpenBSD (though no other platforms that I know of) the PID is a
random number, so there is no wrapping to begin with.
Linux = 2.6 has random pids too.
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] TODO list
Andrew Dunstan wrote:
Bruce Momjian wrote:
Andrew Dunstan wrote:
I thought we had thrashed this out back in August. Certainly the only
thing I recall seeing after I submitted the patch was some stylistic
criticism from Neil, which I addressed in a revised patch.
Anyway, it is in principle doable. That's partly why I adopted a printf
style format string. There are some wrinkles, though:
. interaction with syslog pid/timestamp logging
Yes. If you use syslog, just don't ask for pid/timestamp and let syslog
do it. Of course, right now we are able to send non-pid/timestamp to
syslog _and_ send pid/timestamp to a log file, but that seems like a
rare operation that doesn't justify keeping the various log parameters
separate.
I'm OK with that as long as it is the consensus view. It does seem a
little odd to remove functionality (however rare) for the sake of
configuration neatness, though.
Yes, agreed. Let's explore it. The rare functionality we would be
removing is for:
o User uses syslog
o User wants to log postmaster output to a file too
o User wants timestamp info in the postmaster output file
And the downside is that they get duplicate timestamps in syslog.
Now, if we don't merge timestamp into your new per-line log string, we
end up with a rather illogical and inflexible output format, only to
allow the rare case listed above.
Clearly this isn't a 100% clear decision, but it seems to lean in the
direction of removing the functionality with the goal of providing a
more logical logging API to the users.
Also, I would like to see some kind of session identifier that is more
unique than pid, which wraps around. Ideally we could have 10{pid},
then then the pid wraps around, 20{pid), or something like that.
This requires some thought. ISTM it wouldn't buy you much unless you
made it persistent across server restarts, and possibly not even then. I
don't see it as a reason to hold up these features, though. If someone
wants to tackle this it could be plugged in to the loginfo feature very
easily as an extra escape sequence.
Yes, that was my idea --- let's get this in and we can then add a
session id, and your point about restarts is a good one.
. making sure the info is available when you need to log it - I had to
rearrange a few thing to avoid getting SEGVs, IIRC.
Of course some messages, like postmaster status messages, don't have
some of these fields, like username or host. Is that going to cause
problems for tools that read our log files?
If users want a non-empty info string they will have to teach the tools
to handle it anyway. The point was, however, that rolling up PID and
timestamp into the printf-style format will require some significant
work, because we wouldn't want to lose that info if the user/db weren't
known, whereas the patch currently suppresses all log-info output if
these are not present (i.e. when MyProcPort == NULL).
Oh, good point. That would suggest that maybe we are better off leaving
pid and timestamp as separate options and _not_ merge them into your new
string. I am starting to think having your string print only
session-specific information is the best way.
I wonder if we should rename your GUC log_session_line or something like
that.
Also, the session duration logging part of the patch is orthogonal to the
issue.
You mean query duration? Yes, it is orthoginal.
No, I meant the logging of the end of a session, including its duration,
which was also in the patch.
Oh, I missed that one. It seems like a nice addition. I see you added
it when they ask for log_connections. Good idea.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [HACKERS] TODO list
Jon Jensen wrote:
On Tue, 6 Jan 2004, Andrew Dunstan wrote:
Also, I would like to see some kind of session identifier that is more
unique than pid, which wraps around. Ideally we could have 10{pid},
then then the pid wraps around, 20{pid), or something like that.
This requires some thought. ISTM it wouldn't buy you much unless you
made it persistent across server restarts, and possibly not even then.
And on OpenBSD (though no other platforms that I know of) the PID is a
random number, so there is no wrapping to begin with.
OK, so a sessionid based on prefix+pid won't work portably. If we
*really* want to do it, a cluster-wide sequence generator would probably
be the way to go, but I suspect that with the ability to log session
termination explicitly (which I have already provided) much of the
supposed extra utility would disappear anyway.
cheers
andrew
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] TODO list
Bruce Momjian wrote:
Andrew Dunstan wrote:
Bruce Momjian wrote:
Andrew Dunstan wrote:
I thought we had thrashed this out back in August. Certainly the only
thing I recall seeing after I submitted the patch was some stylistic
criticism from Neil, which I addressed in a revised patch.
Anyway, it is in principle doable. That's partly why I adopted a printf
style format string. There are some wrinkles, though:
. interaction with syslog pid/timestamp logging
Yes. If you use syslog, just don't ask for pid/timestamp and let syslog
do it. Of course, right now we are able to send non-pid/timestamp to
syslog _and_ send pid/timestamp to a log file, but that seems like a
rare operation that doesn't justify keeping the various log parameters
separate.
I'm OK with that as long as it is the consensus view. It does seem a
little odd to remove functionality (however rare) for the sake of
configuration neatness, though.
Yes, agreed. Let's explore it. The rare functionality we would be
removing is for:
o User uses syslog
o User wants to log postmaster output to a file too
o User wants timestamp info in the postmaster output file
And the downside is that they get duplicate timestamps in syslog.
Now, if we don't merge timestamp into your new per-line log string, we
end up with a rather illogical and inflexible output format, only to
allow the rare case listed above.
Clearly this isn't a 100% clear decision, but it seems to lean in the
direction of removing the functionality with the goal of providing a
more logical logging API to the users.
Also, I would like to see some kind of session identifier that is more
unique than pid, which wraps around. Ideally we could have 10{pid},
then then the pid wraps around, 20{pid), or something like that.
This requires some thought. ISTM it wouldn't buy you much unless you
made it persistent across server restarts, and possibly not even then. I
don't see it as a reason to hold up these features, though. If someone
wants to tackle this it could be plugged in to the loginfo feature very
easily as an extra escape sequence.
Yes, that was my idea --- let's get this in and we can then add a
session id, and your point about restarts is a good one.
. making sure the info is available when you need to log it - I had to
rearrange a few thing to avoid getting SEGVs, IIRC.
Of course some messages, like postmaster status messages, don't have
some of these fields, like username or host. Is that going to cause
problems for tools that read our log files?
If users want a non-empty info string they will have to teach the tools
to handle it anyway. The point was, however, that rolling up PID and
timestamp into the printf-style format will require some significant
work, because we wouldn't want to lose that info if the user/db weren't
known, whereas the patch currently suppresses all log-info output if
these are not present (i.e. when MyProcPort == NULL).
Oh, good point. That would suggest that maybe we are better off leaving
pid and timestamp as separate options and _not_ merge them into your new
string. I am starting to think having your string print only
session-specific information is the best way.
I wonder if we should rename your GUC log_session_line or something like
that.
Also, the session duration logging part of the patch is orthogonal to the
issue.
You mean query duration? Yes, it is orthoginal.
No, I meant the logging of the end of a session, including its duration,
which was also in the patch.
Oh, I missed that one. It seems like a nice addition. I see you added
it when they ask for log_connections. Good idea.
I think you are looking at the original patch, not the revised patch,
which is here: http://candle.pha.pa.us/mhonarc/patches2/msg00091.html
and provides a separate GUC var called log_session_end - Neil wanted
these not to be combined, IIRC.
I am agnostic as to the names of the variables.
cheers
andrew
---(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] Reserved words and named function parameters
Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: 1. Make param_name equate to type_name (allowing IDENT or unreserved_keyword), and move the following keywords from unreserved to col_name_keyword status: DOUBLE INOUT NATIONAL OUT 2. Make param_name equate to function_name (allowing IDENT, unreserved_keyword, or func_name_keyword). This requires the above changes plus moving IN from func_name_keyword to fully reserved status. Any opinions which to do, or alternate proposals? I'm leaning slightly to #2, since I doubt anyone is trying to use IN as a function name, but ... I support #2 rather more strongly ;-) After further fooling about, I think it might be better to transfer PRECISION instead of DOUBLE to the col_name_keyword category. The reason we need to do one or the other is create function foo(double precision) ... If both words are unreserved then there are two possible parses --- either double precision as a type spec, or double as a parameter name and precision as a type name. The reason for not wanting to make double even a little bit reserved is that this regression test fails with a syntax error: CREATE TYPE widget ( internallength = 24, input = widget_in, output = widget_out, alignment = double ); We could require people to start quoting double in this context, but I think the path of least resistance is probably to make precision a little bit reserved, instead. Anyone have a strong attachment to custom datatypes named either? regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] processing of unknown datatype
How does the unknown data type get processed, there doesn't seem to be any casts for it? I have a function expecting a timestamp, cstring, cstring if I pass it a timestamp, unknown, unkown it works? if I pass it an unknown, unknown, unkown, it can't be found? Dave -- Dave Cramer 519 939 0336 ICQ # 1467551 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] processing of unknown datatype
Dave Cramer [EMAIL PROTECTED] writes: I have a function expecting a timestamp, cstring, cstring if I pass it a timestamp, unknown, unkown it works? if I pass it an unknown, unknown, unkown, it can't be found? You sure it's can't find it and not can't choose among multiple functions of that name? regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Brokenness in parsing of pg_hba.conf
So one of the client machines for one of my databases at work resides on 10.128.0.45. I had to enter something in pg_hba.conf for it today, as we're bringing this database up. We have a lot of 10/8 subnets, and I use it at home, so I'm accustomed to just using 10.128.45 for the IP. Strangely, however, postgres refused to acknowledge the host when it connected. I checked it again, and sure enough, the IP was right. It turns out that postgres parses pg_hba.conf in an unexpected way -- it does not accept abbreviated ip4 addresses (note that this is common in both ip4 and ip6). In the manpage for inet_aton, we see: INTERNET ADDRESSES (IP VERSION 4) Values specified using the `.' notation take one of the following forms: a.b.c.d a.b.c a.b a When four parts are specified, each is interpreted as a byte of data and assigned, from left to right, to the four bytes of an Internet address. Andrew Dunstan on IRC mentioned that the parser is using the native getaddrinfo. I'm not sure if there are any advantages to this; I've said before that I'm really not a C guy. Paul Vixie had this to say about the convention: What this man page is trying to tell you is that BSD users have historically said 10.73 rather than 10.0.0.73 because they both worked any place where either worked. This includes DNS primary zone files, by the way. I am pretty much assuming that the IETF does not want to standardize this BSD practice, and that we ought not to accept ::10.73 as equivilent to the longer ::10.0.0.73, especially given that the degenerate case given in that man page would be ambiguous with respect to ::1234, a valid RFC1884 address specifier whose low order 16 bits are hexadecimal 1234 rather than decimal 1234. However, that's only _my_ assumption, and some other implementor may feel differently. In fact some other implementor of RFC 1884 might decide to just call inet_aton() for parsing that IPv4 dotted quad, which is what I almost did. The original article can be found here: http://www.cs-ipv6.lancs.ac.uk/ipv6/mail-archive/IPng/1996-06/0037.html I think it is important that postgres behave as expected when handing it a properly formatted ip4 address. However, I'm aware that many people don't even realize this is a valid address. As such, I won't lose any sleep over it, but I thought I'd mention it, since it surprised me today. Thoughts? Alex -- [EMAIL PROTECTED] Alex J. Avriette, Solaris Frobnosticator You can get much farther with a kind word and a gun than you can with a kind word alone. - Al Capone ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] processing of unknown datatype
You are correct, it can't choose Dave On Tue, 2004-01-06 at 19:47, Tom Lane wrote: Dave Cramer [EMAIL PROTECTED] writes: I have a function expecting a timestamp, cstring, cstring if I pass it a timestamp, unknown, unkown it works? if I pass it an unknown, unknown, unkown, it can't be found? You sure it's can't find it and not can't choose among multiple functions of that name? regards, tom lane -- Dave Cramer 519 939 0336 ICQ # 1467551 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] processing of unknown datatype
So how can I create a function that it will choose, the option of casting is not available to me Dave On Tue, 2004-01-06 at 19:47, Tom Lane wrote: Dave Cramer [EMAIL PROTECTED] writes: I have a function expecting a timestamp, cstring, cstring if I pass it a timestamp, unknown, unkown it works? if I pass it an unknown, unknown, unkown, it can't be found? You sure it's can't find it and not can't choose among multiple functions of that name? regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org -- Dave Cramer 519 939 0336 ICQ # 1467551 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Brokenness in parsing of pg_hba.conf
A few points. 1. clarification of my IRC comment: A quick examination seems to shaw that we use the native getaddrinfo() where it exists, otherwise we use our own, which in turn calls inet_ntoa(). 2. ip6 has a well defined standard for abbreviation, and is quite important to have since ip6 addresses would otherwise often be tediously long. I haven't found a comparable standard for abbreviating IP4 addresses. There appears to be a convention relying on behaviour of inet_aton, and perhaps hallowed by history, but by any measure surely brain dead and counter intuitive. Why would a.b.c become a.b.0.c and a.b become a.0.0.b? On Linux it is not even documented. See the email from Paul Vixie cited below for futher gory details, including a citation of rfc1208 that specifies exactly 4 parts for a dotted notation. It's not surprising that he starts one sentence thus: Now, before you laugh so hard you fall out of your collective seats,. 3. Maybe some people are used to it. In around 15 years of using and administering Unix I haven't tripped over this before, so I suspect it's probably not a huge problem :-) 4. My personal preference would be that if any change is made it would be to insist on an unabbreviated dotted quad for ip4. Alternatively, we need to make sure that whatever we do is consistent. That might not be possible, however, if different platforms or different library calls behave differently. cheers andrew Alex J. Avriette wrote: So one of the client machines for one of my databases at work resides on 10.128.0.45. I had to enter something in pg_hba.conf for it today, as we're bringing this database up. We have a lot of 10/8 subnets, and I use it at home, so I'm accustomed to just using 10.128.45 for the IP. Strangely, however, postgres refused to acknowledge the host when it connected. I checked it again, and sure enough, the IP was right. It turns out that postgres parses pg_hba.conf in an unexpected way -- it does not accept abbreviated ip4 addresses (note that this is common in both ip4 and ip6). In the manpage for inet_aton, we see: INTERNET ADDRESSES (IP VERSION 4) Values specified using the `.' notation take one of the following forms: a.b.c.d a.b.c a.b a When four parts are specified, each is interpreted as a byte of data and assigned, from left to right, to the four bytes of an Internet address. Andrew Dunstan on IRC mentioned that the parser is using the native getaddrinfo. I'm not sure if there are any advantages to this; I've said before that I'm really not a C guy. Paul Vixie had this to say about the convention: What this man page is trying to tell you is that BSD users have historically said 10.73 rather than 10.0.0.73 because they both worked any place where either worked. This includes DNS primary zone files, by the way. I am pretty much assuming that the IETF does not want to standardize this BSD practice, and that we ought not to accept ::10.73 as equivilent to the longer ::10.0.0.73, especially given that the degenerate case given in that man page would be ambiguous with respect to ::1234, a valid RFC1884 address specifier whose low order 16 bits are hexadecimal 1234 rather than decimal 1234. However, that's only _my_ assumption, and some other implementor may feel differently. In fact some other implementor of RFC 1884 might decide to just call inet_aton() for parsing that IPv4 dotted quad, which is what I almost did. The original article can be found here: http://www.cs-ipv6.lancs.ac.uk/ipv6/mail-archive/IPng/1996-06/0037.html I think it is important that postgres behave as expected when handing it a properly formatted ip4 address. However, I'm aware that many people don't even realize this is a valid address. As such, I won't lose any sleep over it, but I thought I'd mention it, since it surprised me today. Thoughts? Alex -- [EMAIL PROTECTED] Alex J. Avriette, Solaris Frobnosticator You can get much farther with a kind word and a gun than you can with a kind word alone. - Al Capone ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [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] processing of unknown datatype
Dave Cramer [EMAIL PROTECTED] writes: So how can I create a function that it will choose, the option of casting is not available to me If the inputs are all unknown, I think your only choice is to not have more than one function of that name (and number of parameters). Otherwise the system simply doesn't have a basis for making a choice. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Brokenness in parsing of pg_hba.conf
On Tue, Jan 06, 2004 at 10:52:19PM -0500, Andrew Dunstan wrote: 4. My personal preference would be that if any change is made it would be to insist on an unabbreviated dotted quad for ip4. Alternatively, we I really think this is the wrong way to approach it. The 127.1 convention is common, and valid. To disallow it because you haven't experienced it is pretty egocentric. If you would instead object on the grounds of it being difficult to implement, or non portable, or outright incorrect, I would be fine with it. But the attitude of I've never seen this, and I don't like it, regardless of the documentation just sucks. need to make sure that whatever we do is consistent. That might not be possible, however, if different platforms or different library calls behave differently. In how many places are we using inet_aton? I see in the docs: http://www.postgresql.org/docs/7.4/static/datatype-net-types.html#DATATYPE-INET It looks like the abbreviated addresses there refer to networks (like the RFC says). Additionally, if you give it '192.168.1/32', you get 192.168.1.0/32. This is even weirder than I expected. I'd really like to hear from others what their opinions on this are. alex -- [EMAIL PROTECTED] Alex J. Avriette, Shepherd of wayward Database Administrators We are paying through the nose to be ignorant. - Larry Ellison ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Brokenness in parsing of pg_hba.conf
Andrew Dunstan [EMAIL PROTECTED] writes: 1. clarification of my IRC comment: A quick examination seems to shaw that we use the native getaddrinfo() where it exists, otherwise we use our own, which in turn calls inet_ntoa(). 2. ip6 has a well defined standard for abbreviation, and is quite important to have since ip6 addresses would otherwise often be tediously long. I haven't found a comparable standard for abbreviating IP4 addresses. AFAICS, Alex is quite far out in left field to believe that this is a standard notation. The fact that some BSD platforms have accepted it does not make it standard, especially not when Vixie's research shows that there is no RFC to legitimize it. (Personally I never heard of it before either, not that that proves much...) 4. My personal preference would be that if any change is made it would be to insist on an unabbreviated dotted quad for ip4. I can't get excited about replacing or second-guessing the platform's getaddrinfo() or inet_aton() implementation. If you don't like how those library routines behave, forward your bug report appropriately --- but it's not Postgres' problem. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Brokenness in parsing of pg_hba.conf
Alex J. Avriette [EMAIL PROTECTED] writes: I really think this is the wrong way to approach it. The 127.1 convention is common, and valid. AFAICS your own platform's C library doesn't support it, which means you are on pretty shaky ground to make this claim. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Brokenness in parsing of pg_hba.conf
Alex J. Avriette [EMAIL PROTECTED] writes: In how many places are we using inet_aton? BTW, further digging shows that when the platform has neither getaddrinfo nor inet_aton, we fall back to src/port/inet_aton.c, which is a BSD-derived bit of code that behaves exactly as per your man page quote. So I'm pretty well convinced that your gripe is misdirected: you should be complaining to the authors of your C library. regards, tom lane ---(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] Brokenness in parsing of pg_hba.conf
On Tue, Jan 06, 2004 at 11:38:44PM -0500, Tom Lane wrote: AFAICS, Alex is quite far out in left field to believe that this is a standard notation. The fact that some BSD platforms have accepted it How did I know you'd say that, Tom? By standard, I mean, many people use it. Not, some standard is defined. For me, the manpage is enough. Additionally, the fact that I (and you) can ping 127.1 on our (your) machine is enough for me. Go on, try it. does not make it standard, especially not when Vixie's research shows that there is no RFC to legitimize it. (Personally I never heard of Vixie is known for being slightly ... irritable. If he encounters something he doesn't like, his first response is oh, that's stupid. It seems strange that Linux, BSD, and Solaris (I can investigate IRIX and OSF1 tomorrow) all support it if it is either incorrect or nonstandard. We're not talking about just BSD here. 4. My personal preference would be that if any change is made it would be to insist on an unabbreviated dotted quad for ip4. I can't get excited about replacing or second-guessing the platform's getaddrinfo() or inet_aton() implementation. If you don't like how Given on both Solaris (my database server) and OpenBSD (the machine from which that manpage came from) I can connect to 127.1, I think you must be mistaken here. What made you think that it isn't supported? those library routines behave, forward your bug report appropriately --- but it's not Postgres' problem. There isn't any point in filing a bug if it will be ignored. alex -- [EMAIL PROTECTED] Alex J. Avriette, Unix Systems Gladiator You cannot invade the mainland United States. There would be a rifle behind each blade of grass. - Admiral Isoroku Yamamoto ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
