Re: [HACKERS] dblink versus long connection strings
I have views that use the dblink(connStr text, sql text) call. They cannot use a two-step process. So postgres 9.0 has broken all of those views. Is there a straightforward solution to this? -- View this message in context: http://postgresql.1045698.n5.nabble.com/dblink-versus-long-connection-strings-tp3275575p3284620.html Sent from the PostgreSQL - hackers mailing list archive at Nabble.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] dblink versus long connection strings
On Tue, Nov 30, 2010 at 01:01, queej d...@authentrics.com wrote: I have views that use the dblink(connStr text, sql text) call. They cannot use a two-step process. So postgres 9.0 has broken all of those views. Is there a straightforward solution to this? Could you explain your views? I cannot get any warnings from dblink(connStr text, sql text) with long connStr. Also, I wonder two things: * dblink(connStr text, sql text) never raises warning logs even without the recent fix, because they don't register connection names. * Connection names could be truncated, but connection strings are never truncated. I'm not sure why connection strings are logged in your log. -- Itagaki Takahiro -- 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] dblink versus long connection strings
On Tue, Nov 23, 2010 at 02:21, Tom Lane t...@sss.pgh.pa.us wrote: In any case I don't see an argument why warning on connection creation isn't sufficient. I'll check all versions of dblink. truncate_identifier() will be called with warn=false in all cases except dblink_coneect() - createNewConnection(). -- Itagaki Takahiro -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] dblink versus long connection strings
This bug report: http://archives.postgresql.org/pgsql-bugs/2010-11/msg00139.php shows that this patch was ill-considered: http://archives.postgresql.org/pgsql-committers/2010-06/msg00013.php and this later attempt didn't fix it, because it still misbehaves in HEAD: http://archives.postgresql.org/pgsql-committers/2010-06/msg00070.php not to mention that that second patch didn't even touch pre-8.4 branches. I'm inclined to think that we should just change all the truncate_identifier calls to warn=false, and forget about providing identifier-truncated warnings here. It's too difficult to tell whether a string is really meant as an identifier. 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] dblink versus long connection strings
On Tue, Nov 23, 2010 at 01:27, Tom Lane t...@sss.pgh.pa.us wrote: This bug report: http://archives.postgresql.org/pgsql-bugs/2010-11/msg00139.php shows that this patch was ill-considered: http://archives.postgresql.org/pgsql-committers/2010-06/msg00013.php and this later attempt didn't fix it, because it still misbehaves in HEAD: http://archives.postgresql.org/pgsql-committers/2010-06/msg00070.php not to mention that that second patch didn't even touch pre-8.4 branches. I'm inclined to think that we should just change all the truncate_identifier calls to warn=false, and forget about providing identifier-truncated warnings here. It's too difficult to tell whether a string is really meant as an identifier. It is not a truncated identifier, but I think the truncation is still worth warning because we cannot distinguish two connections that differ only 63 bytes. Do we need another logic to name non-named connections? For example, md5 hash of the connection string. -- Itagaki Takahiro -- 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] dblink versus long connection strings
Itagaki Takahiro itagaki.takah...@gmail.com writes: On Tue, Nov 23, 2010 at 01:27, Tom Lane t...@sss.pgh.pa.us wrote: I'm inclined to think that we should just change all the truncate_identifier calls to warn=false, and forget about providing identifier-truncated warnings here. Â It's too difficult to tell whether a string is really meant as an identifier. It is not a truncated identifier, but I think the truncation is still worth warning because we cannot distinguish two connections that differ only 63 bytes. The problem is to not give a warning when the string isn't meant as a connection name at all, but as a libpq conninfo string (which can perfectly reasonably run to more than 63 characters). Most if not all of the dblink functions will accept either. Perhaps a reasonable compromise is to issue the truncation warnings when an overlength name is being *entered* into the connection table, but not for simple lookups. 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] dblink versus long connection strings
On 11/22/2010 11:51 AM, Tom Lane wrote: Itagaki Takahiroitagaki.takah...@gmail.com writes: On Tue, Nov 23, 2010 at 01:27, Tom Lanet...@sss.pgh.pa.us wrote: I'm inclined to think that we should just change all the truncate_identifier calls to warn=false, and forget about providing identifier-truncated warnings here. Â It's too difficult to tell whether a string is really meant as an identifier. It is not a truncated identifier, but I think the truncation is still worth warning because we cannot distinguish two connections that differ only63 bytes. The problem is to not give a warning when the string isn't meant as a connection name at all, but as a libpq conninfo string (which can perfectly reasonably run to more than 63 characters). Most if not all of the dblink functions will accept either. Perhaps a reasonable compromise is to issue the truncation warnings when an overlength name is being *entered* into the connection table, but not for simple lookups. Can't we distinguish a name from a conninfo string by the presence of an = sign? cheers andrew -- 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] dblink versus long connection strings
Andrew Dunstan and...@dunslane.net writes: On 11/22/2010 11:51 AM, Tom Lane wrote: Perhaps a reasonable compromise is to issue the truncation warnings when an overlength name is being *entered* into the connection table, but not for simple lookups. Can't we distinguish a name from a conninfo string by the presence of an = sign? No, because = isn't disallowed in names ... 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] dblink versus long connection strings
On 11/22/2010 12:08 PM, Tom Lane wrote: Andrew Dunstanand...@dunslane.net writes: On 11/22/2010 11:51 AM, Tom Lane wrote: Perhaps a reasonable compromise is to issue the truncation warnings when an overlength name is being *entered* into the connection table, but not for simple lookups. Can't we distinguish a name from a conninfo string by the presence of an = sign? No, because = isn't disallowed in names ... Ok, true, but it still might not be a bad heuristic to use for issuing a warning on lookup. cheers andrew -- 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] dblink versus long connection strings
Andrew Dunstan and...@dunslane.net writes: On 11/22/2010 12:08 PM, Tom Lane wrote: No, because = isn't disallowed in names ... Ok, true, but it still might not be a bad heuristic to use for issuing a warning on lookup. The fine manual says that using = in a connection name might be unwise because of the risk of confusion. It doesn't say that you should expect to get a NOTICE every single time you use the name. People have complained of postmaster log bloat for lots less reason than this. In any case I don't see an argument why warning on connection creation isn't sufficient. 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] dblink versus long connection strings
On 11/22/2010 12:21 PM, Tom Lane wrote: Andrew Dunstanand...@dunslane.net writes: On 11/22/2010 12:08 PM, Tom Lane wrote: No, because = isn't disallowed in names ... Ok, true, but it still might not be a bad heuristic to use for issuing a warning on lookup. The fine manual says that using = in a connection name might be unwise because of the risk of confusion. It doesn't say that you should expect to get a NOTICE every single time you use the name. People have complained of postmaster log bloat for lots less reason than this. In any case I don't see an argument why warning on connection creation isn't sufficient. OK. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
