Re: [HACKERS] dblink versus long connection strings

2010-11-29 Thread queej
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:

Re: [HACKERS] dblink versus long connection strings

2010-11-29 Thread Itagaki Takahiro
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

Re: [HACKERS] dblink versus long connection strings

2010-11-25 Thread Itagaki Takahiro
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() -

[HACKERS] dblink versus long connection strings

2010-11-22 Thread Tom Lane
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:

Re: [HACKERS] dblink versus long connection strings

2010-11-22 Thread Itagaki Takahiro
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

Re: [HACKERS] dblink versus long connection strings

2010-11-22 Thread Tom Lane
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

Re: [HACKERS] dblink versus long connection strings

2010-11-22 Thread Andrew Dunstan
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

Re: [HACKERS] dblink versus long connection strings

2010-11-22 Thread Tom Lane
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

Re: [HACKERS] dblink versus long connection strings

2010-11-22 Thread Andrew Dunstan
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.

Re: [HACKERS] dblink versus long connection strings

2010-11-22 Thread Tom Lane
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

Re: [HACKERS] dblink versus long connection strings

2010-11-22 Thread Andrew Dunstan
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