Thread: dblink versus long connection strings

dblink versus long connection strings

From
Tom Lane
Date:
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


Re: dblink versus long connection strings

From
Itagaki Takahiro
Date:
On Tue, Nov 23, 2010 at 01:27, Tom Lane <tgl@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


Re: dblink versus long connection strings

From
Tom Lane
Date:
Itagaki Takahiro <itagaki.takahiro@gmail.com> writes:
> On Tue, Nov 23, 2010 at 01:27, Tom Lane <tgl@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


Re: dblink versus long connection strings

From
Andrew Dunstan
Date:

On 11/22/2010 11:51 AM, Tom Lane wrote:
> Itagaki Takahiro<itagaki.takahiro@gmail.com>  writes:
>> On Tue, Nov 23, 2010 at 01:27, Tom Lane<tgl@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.

Can't we distinguish a name from a conninfo string by the presence of an 
= sign?

cheers

andrew


Re: dblink versus long connection strings

From
Tom Lane
Date:
Andrew Dunstan <andrew@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


Re: dblink versus long connection strings

From
Andrew Dunstan
Date:

On 11/22/2010 12:08 PM, Tom Lane wrote:
> Andrew Dunstan<andrew@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


Re: dblink versus long connection strings

From
Tom Lane
Date:
Andrew Dunstan <andrew@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


Re: dblink versus long connection strings

From
Andrew Dunstan
Date:

On 11/22/2010 12:21 PM, Tom Lane wrote:
> Andrew Dunstan<andrew@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


Re: dblink versus long connection strings

From
Itagaki Takahiro
Date:
On Tue, Nov 23, 2010 at 02:21, Tom Lane <tgl@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


Re: dblink versus long connection strings

From
queej
Date:
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.


Re: dblink versus long connection strings

From
Itagaki Takahiro
Date:
On Tue, Nov 30, 2010 at 01:01, queej <dqj@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
connectionnames. 
* Connection names could be truncated, but connection strings are never truncated. I'm not sure why connection strings
arelogged in your log. 

--
Itagaki Takahiro