On Wed, Feb 27, 2013 at 12:09 PM, Stephen Frost sfr...@snowman.net 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
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-hidden
On Mon, Mar 4, 2013 at 11:39 AM, Stephen Frost sfr...@snowman.net 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
* 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
On Mon, Mar 4, 2013 at 11:54 AM, Stephen Frost sfr...@snowman.net 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
2013/2/27 Stephen Frost sfr...@snowman.net:
* 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
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
2013/2/27 Stephen Frost sfr...@snowman.net:
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
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)'
2013/2/27 Stephen Frost sfr...@snowman.net:
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
* 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 should
2013/2/27 Stephen Frost sfr...@snowman.net:
* 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.
* 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 sfr...@snowman.net:
* 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
* 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
Stephen Frost sfr...@snowman.net 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
* 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
On 02/26/2013 02:12 PM, Tom Lane wrote:
Stephen Frost sfr...@snowman.net 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
* 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 cp
from the \df output to see the function. But here's what happens:
I was thinking along the same lines. This will
Stephen Frost sfr...@snowman.net 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 cp
from the \df output to see the function. But here's what happens:
I was
* 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
2013/2/26 Stephen Frost sfr...@snowman.net:
* 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
Pavel Stehule pavel.steh...@gmail.com writes:
2013/2/23 Stephen Frost sfr...@snowman.net:
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
2013/2/23 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
2013/2/23 Stephen Frost sfr...@snowman.net:
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
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 not
2013/2/24 Stephen Frost sfr...@snowman.net:
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
* 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 could
2013/2/24 Stephen Frost sfr...@snowman.net:
* 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
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 pass
2013/2/23 Stephen Frost sfr...@snowman.net:
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?
2013/2/20 Josh Kupershmidt schmi...@gmail.com:
On Wed, Jan 23, 2013 at 12:06 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
2013/1/14 Tom Lane t...@sss.pgh.pa.us:
Well, fine, but then it should fix both of them and remove
minimal_error_message altogether. I would however suggest
On Wed, Jan 23, 2013 at 12:06 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
2013/1/14 Tom Lane t...@sss.pgh.pa.us:
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
2013/1/14 Tom Lane t...@sss.pgh.pa.us:
Robert Haas robertmh...@gmail.com writes:
On Mon, Jan 14, 2013 at 11:56 AM, Tom Lane t...@sss.pgh.pa.us 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
Pavel Stehule pavel.steh...@gmail.com 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
2013/1/14 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com 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)
On Mon, Jan 14, 2013 at 11:56 AM, Tom Lane t...@sss.pgh.pa.us 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
Robert Haas robertmh...@gmail.com writes:
On Mon, Jan 14, 2013 at 11:56 AM, Tom Lane t...@sss.pgh.pa.us 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
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
