On Mon, Mar 4, 2013 at 11:54 AM, Stephen Frost wrote:
> Yeah, no, I don't think we should go in this direction. The whole
> TraceQuery thing is entirely redundant to what's already there and which
> should have been used from the beginning. This would be adding on to
> that mistake instead of fi
* Josh Kupershmidt (schmi...@gmail.com) wrote:
> Sorry, this second version posted by Pavel:
> http://www.postgresql.org/message-id/cafj8prb3-tov5s2dcgshp+vedyk9s97d7hn7rdmmw9ztrj-...@mail.gmail.com
Yeah, no, I don't think we should go in this direction. The whole
TraceQuery thing is entirely red
On Mon, Mar 4, 2013 at 11:39 AM, Stephen Frost wrote:
> Josh,
>
> * Josh Kupershmidt (schmi...@gmail.com) wrote:
>> I still think this patch is an improvement over the status quo, and is
>> committable as-is. Yes, the patch doesn't address the existing
>> ugliness with minimal_error_message() and
Josh,
* Josh Kupershmidt (schmi...@gmail.com) wrote:
> I still think this patch is an improvement over the status quo, and is
> committable as-is. Yes, the patch doesn't address the existing
> ugliness with minimal_error_message() and sidestepping PSQLexec(), but
> at least it fixes the --echo-hid
On Wed, Feb 27, 2013 at 12:09 PM, Stephen Frost wrote:
> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
>> I don't agree so it works well - you cannot use short type names is
>> significant issue
>
> This is for psql. In what use-case do you see that being a serious
> limitation?
>
> I might su
2013/2/27 Stephen Frost :
> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
>> I don't agree so it works well - you cannot use short type names is
>> significant issue
>
> This is for psql. In what use-case do you see that being a serious
> limitation?
>
> I might support having psql be able to f
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> I don't agree so it works well - you cannot use short type names is
> significant issue
This is for psql. In what use-case do you see that being a serious
limitation?
I might support having psql be able to fall-back to checking if the
function n
2013/2/27 Stephen Frost :
> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
>> autocomplete send a SQL query in every iteration to server - so it is
>> not any new overhead. And if we should to write some smarted routine,
>> then I prefer server side due better reusability and better exception
>>
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> autocomplete send a SQL query in every iteration to server - so it is
> not any new overhead. And if we should to write some smarted routine,
> then I prefer server side due better reusability and better exception
> processing than psql environment
2013/2/27 Stephen Frost :
> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
>> we cannot use autocomplete or if we use, then more precious code is on
>> server side still - everywhere where function autocomplete is used,
>> then function signature is reparesed again on server side.
>
> This doesn
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> we cannot use autocomplete or if we use, then more precious code is on
> server side still - everywhere where function autocomplete is used,
> then function signature is reparesed again on server side.
This doesn't make any sense to me.
We shoul
2013/2/27 Stephen Frost :
> Pavel,
>
> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
>> this autocomplete routine doesn't know type synonyms
>>
>> so you cannot use int, varchar, ... :(
>
> Yes, I covered that and it's perfectly fine, imv. Results from
> tab-completion and from \df output shoul
Pavel,
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> this autocomplete routine doesn't know type synonyms
>
> so you cannot use int, varchar, ... :(
Yes, I covered that and it's perfectly fine, imv. Results from
tab-completion and from \df output should work just fine.
'\df myfunc(int)' d
2013/2/27 Stephen Frost :
> Pavel,
>
> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
>> this is not hard task, hard task is correct identification related function
>>
>> see FuncnameGetCandidates() function
>
> We're not limited to writing C code here though and I think we've
> already solved it
Pavel,
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> this is not hard task, hard task is correct identification related function
>
> see FuncnameGetCandidates() function
We're not limited to writing C code here though and I think we've
already solved it, though I admit it wasn't where I ori
2013/2/26 Stephen Frost :
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Dunno, I think that's going to result in a very large chunk of mostly
>> duplicative code in psql. regprocedurein() is fairly short because it
>> can rely on a ton of code from the parser, but psql won't have that
>> luxury.
>
>
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Dunno, I think that's going to result in a very large chunk of mostly
> duplicative code in psql. regprocedurein() is fairly short because it
> can rely on a ton of code from the parser, but psql won't have that
> luxury.
Parsing/tokenizing a CSV string in
Stephen Frost writes:
> * Andrew Dunstan (and...@dunslane.net) wrote:
>> If we're going to mess with this area can I put in a plea to get \ef
>> and \sf to handle full parameter specs? I want to be able to c&p
>> from the \df output to see the function. But here's what happens:
> I was thinking a
* Andrew Dunstan (and...@dunslane.net) wrote:
> If we're going to mess with this area can I put in a plea to get \ef
> and \sf to handle full parameter specs? I want to be able to c&p
> from the \df output to see the function. But here's what happens:
I was thinking along the same lines. This wil
On 02/26/2013 02:12 PM, Tom Lane wrote:
Stephen Frost writes:
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
Minimally \ef needs exact specification - you cannot to edit more
functions in same time. So we have to be able identify if there are no
selected function or if there are more functi
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Well, actually I think Pavel's got a point. What about overloaded
> functions? In \df we don't try to solve that problem, we just print
> them all:
To be honest, I was reading through that code the other night and could
have sworn that I saw us doing some
Stephen Frost writes:
> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
>> Minimally \ef needs exact specification - you cannot to edit more
>> functions in same time. So we have to be able identify if there are no
>> selected function or if there are more functions. We can write a
>> auxiliary f
2013/2/24 Stephen Frost :
> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
>> it is not possible - both fragments has different purpose. Code in \ef
>> or \sf should to select exactly one function based on complete
>> function signature, \df try to show list of functions filtered by
>> name.
>
>
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> it is not possible - both fragments has different purpose. Code in \ef
> or \sf should to select exactly one function based on complete
> function signature, \df try to show list of functions filtered by
> name.
I don't buy that argument. You cou
2013/2/24 Stephen Frost :
> Pavel,
>
> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
>> I am looking on this code now, and it is not easy as I though - there
>> are two possible errors: not found or found more - so returning
>> InvalidOid is not enough - and then some "new lookup" function is no
Pavel,
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> I am looking on this code now, and it is not easy as I though - there
> are two possible errors: not found or found more - so returning
> InvalidOid is not enough - and then some "new lookup" function is not
> simple or is ugly - and I am n
2013/2/23 Tom Lane :
> Pavel Stehule writes:
>> 2013/2/23 Stephen Frost :
>>> Why is that? lookup_function_oid() only collects the oid to pass to
>>> get_create_function_cmd(), why not just issue one query to the backend?
>>> And use PSQLexec() to boot and get --echo-hidden, etc, for free? And
>
Pavel Stehule writes:
> 2013/2/23 Stephen Frost :
>> Why is that? lookup_function_oid() only collects the oid to pass to
>> get_create_function_cmd(), why not just issue one query to the backend?
>> And use PSQLexec() to boot and get --echo-hidden, etc, for free? And
>> eliminate the one-off err
2013/2/23 Stephen Frost :
> Pavel,
>
> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
>> We cannot to remove minimal_error_message() because there
>> are >>two<< SQL queries and if we do fault tolerant oid lookup, then
>> still pg_get_functiondef can raise exception.
>
> Why is that? lookup_fun
Pavel,
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> We cannot to remove minimal_error_message() because there
> are >>two<< SQL queries and if we do fault tolerant oid lookup, then
> still pg_get_functiondef can raise exception.
Why is that? lookup_function_oid() only collects the oid to
2013/2/20 Josh Kupershmidt :
> On Wed, Jan 23, 2013 at 12:06 PM, Pavel Stehule
> wrote:
>> 2013/1/14 Tom Lane :
>>> Well, fine, but then it should fix both of them and remove
>>> minimal_error_message altogether. I would however suggest eyeballing
>>> what happens when you try "\ef nosuchfunctio
On Wed, Jan 23, 2013 at 12:06 PM, Pavel Stehule wrote:
> 2013/1/14 Tom Lane :
>> Well, fine, but then it should fix both of them and remove
>> minimal_error_message altogether. I would however suggest eyeballing
>> what happens when you try "\ef nosuchfunction" (with or without -E).
>> I'm pretty
2013/1/14 Tom Lane :
> Robert Haas writes:
>> On Mon, Jan 14, 2013 at 11:56 AM, Tom Lane wrote:
>>> So far as I can tell, get_create_function_cmd (and lookup_function_oid
>>> too) were intentionally designed to not show their queries, and for that
>>> matter they go out of their way to produce te
Robert Haas writes:
> On Mon, Jan 14, 2013 at 11:56 AM, Tom Lane wrote:
>> So far as I can tell, get_create_function_cmd (and lookup_function_oid
>> too) were intentionally designed to not show their queries, and for that
>> matter they go out of their way to produce terse error output if they
>>
On Mon, Jan 14, 2013 at 11:56 AM, Tom Lane wrote:
> So far as I can tell, get_create_function_cmd (and lookup_function_oid
> too) were intentionally designed to not show their queries, and for that
> matter they go out of their way to produce terse error output if they
> fail. I'm not sure why we
2013/1/14 Tom Lane :
> Pavel Stehule writes:
>> this is very simple patch - it enables hidden_queries for commands
>> \sf and \ef to be consistent with other describing commands.
>
> So far as I can tell, get_create_function_cmd (and lookup_function_oid
> too) were intentionally designed to not
Pavel Stehule writes:
> this is very simple patch - it enables hidden_queries for commands
> \sf and \ef to be consistent with other describing commands.
So far as I can tell, get_create_function_cmd (and lookup_function_oid
too) were intentionally designed to not show their queries, and for th
Hello
this is very simple patch - it enables hidden_queries for commands
\sf and \ef to be consistent with other describing commands.
bash-4.1$ ./psql postgres -E
psql (9.3devel)
Type "help" for help.
postgres=# \sf+ foo
* QUERY **
SELECT pg_catalog.pg_get_functiondef(16385)
**
38 matches
Mail list logo
