On Thu, Feb 14, 2013 at 10:03 AM, Stephen Frost wrote:
> * Merlin Moncure (mmonc...@gmail.com) wrote:
>> That doesn't work. functions don't allow arbitrary returned columns.
>> CALL should support this.
>
> That's yet another discussion, though for a preview, you could just
> return a single text
On Thu, Feb 14, 2013 at 10:32 AM, Pavel Stehule wrote:
> 2013/2/14 Stephen Frost :
>> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
>>> it is not true
>>
>> It most certainly is true- did you look at the command?
>>
>> SELECT top10('foo');
>>
>> Note that it's "top10", implying that it'd return
Stephen Frost writes:
> This discussion isn't going to change my feelings on this particular
> misfeature. If others feel it's valuable and important then they can
> certainly speak-up.
I think the same --- a new backslash command for this is absolutely not
worth its weight compared to using "TA
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> it is not easy - we have no available any formatting support on server side
Sure we do.
> so then you need to supply lot of libpq code
No, you don't.
This discussion isn't going to change my feelings on this particular
misfeature. If others fe
2013/2/14 Stephen Frost :
> * Merlin Moncure (mmonc...@gmail.com) wrote:
>> That doesn't work. functions don't allow arbitrary returned columns.
>> CALL should support this.
>
> That's yet another discussion, though for a preview, you could just
> return a single text column from the function in w
2013/2/14 Stephen Frost :
> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
>> it is not true
>
> It most certainly is true- did you look at the command?
>
> SELECT top10('foo');
>
> Note that it's "top10", implying that it'd return the first 10 records.
> That's only 2 characters more than:
In c
* Merlin Moncure (mmonc...@gmail.com) wrote:
> That doesn't work. functions don't allow arbitrary returned columns.
> CALL should support this.
That's yet another discussion, though for a preview, you could just
return a single text column from the function in which you do whatever
formatting you
On Thu, Feb 14, 2013 at 8:43 AM, Stephen Frost wrote:
> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
>> My proposal should not replace stored procedures.
>
> Stored procedures, with actual transaction-management capabilities, is a
> completely different topic which isn't usefully involved here
Pavel Stehule escribió:
> 2013/2/14 Stephen Frost :
> > * Merlin Moncure (mmonc...@gmail.com) wrote:
> >> CALL top10('foo');
> >>
> >> which seems more general and just as terse. So I think implementing
> >> call syntax is probably topping my 'wanted feature' list.
> >
> > We have that, it's calle
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> My proposal should not replace stored procedures.
Stored procedures, with actual transaction-management capabilities, is a
completely different topic which isn't usefully involved here.
> The core of my proposal was using autocomplete for one oft
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> it is not true
It most certainly is true- did you look at the command?
SELECT top10('foo');
Note that it's "top10", implying that it'd return the first 10 records.
That's only 2 characters more than:
CALL top10('foo');
It's not as short as '\v
2013/2/14 Stephen Frost :
> * Merlin Moncure (mmonc...@gmail.com) wrote:
>> CALL top10('foo');
>>
>> which seems more general and just as terse. So I think implementing
>> call syntax is probably topping my 'wanted feature' list.
>
> We have that, it's called 'SELECT' and it's only 2 more characte
On 2013-02-14 09:33:51 -0500, Stephen Frost wrote:
> * Merlin Moncure (mmonc...@gmail.com) wrote:
> > CALL top10('foo');
> >
> > which seems more general and just as terse. So I think implementing
> > call syntax is probably topping my 'wanted feature' list.
>
> We have that, it's called 'SELECT
2013/2/14 Merlin Moncure :
> On Thu, Feb 14, 2013 at 1:25 AM, Pavel Stehule
> wrote:
>> few year ago I proposed a implementation of macros - and I wrote a
>> prototype - enhanced psql
>>
>> http://okbob.blogspot.cz/search?q=epsql
>>
>> but now I don't think so enhancing psql in this direction is
* Merlin Moncure (mmonc...@gmail.com) wrote:
> CALL top10('foo');
>
> which seems more general and just as terse. So I think implementing
> call syntax is probably topping my 'wanted feature' list.
We have that, it's called 'SELECT' and it's only 2 more characters..
Thanks,
On Thu, Feb 14, 2013 at 1:25 AM, Pavel Stehule wrote:
> few year ago I proposed a implementation of macros - and I wrote a
> prototype - enhanced psql
>
> http://okbob.blogspot.cz/search?q=epsql
>
> but now I don't think so enhancing psql in this direction is good way.
> Enhanced console needs cre
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> Native implementation of \vt is terrible simple - and it is generic
> and usual task
I'm still a -1 on this. We don't have anything like this today and I
don't think it's a good idea to try adding these kinds of
shortcuts-for-generic-SQL to psql'
Hello
>
>
> I liked this idea, but thinking better we can implement a way to users
> create your own meta-commands to run:
>
> * another meta commands (like an alias)
> * SRFs
> * arbitrary SQLs
>
> All of them must accept arguments... some like this:
>
> \mset vt :table :rows 'select * from :tab
On Wed, Feb 13, 2013 at 6:07 PM, Pavel Stehule wrote:
> Hello
>
> probably one from my top ten SQL statement will be
>
> SELECT * FROM some_relation LIMIT 10
>
> what do you thinking about creating special statement for this purpose?
>
> possible syntax
>
> -- ViewTable
> \vt table_name [rows]
>
>
Ian Lawrence Barwick writes:
> 2013/2/14 Tom Lane :
>> Can't you pretty much do this already in psql with FETCH_COUNT? I see
>> no good reason to invent more SQL syntax.
> Doesn't that just split up the retrieval of the result set into blocks of
> FETCH_COUNT rows, i.e. does not limit the result
2013/2/14 Tom Lane :
> Stephen Frost writes:
>> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
>>> SELECT * FROM some_relation LIMIT 10
>>>
>>> what do you thinking about creating special statement for this purpose?
>
>> I'd rather extend TABLE to support a limit clause or something.
>
> Can't y
Stephen Frost writes:
> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
>> SELECT * FROM some_relation LIMIT 10
>>
>> what do you thinking about creating special statement for this purpose?
> I'd rather extend TABLE to support a limit clause or something.
Can't you pretty much do this already
2013/2/13 Stephen Frost :
> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
>> and I expect so limit 10 is default
>>
>> table statement is little bit different creature (and mainly it is server
>> side)
>
> I don't really see the value in this.
it is just shortcut for often used query - nothing
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> and I expect so limit 10 is default
>
> table statement is little bit different creature (and mainly it is server
> side)
I don't really see the value in this.
Thanks,
Stephen
signature.asc
Description: Digital signat
2013/2/13 Stephen Frost :
> * Erik Rijkers (e...@xs4all.nl) wrote:
>> No need; that already does work, e.g.:
>>
>> testdb=# table pg_database limit 3;
>
> Oh.
>
>> Not in the documentation, but I hope it won't get removed -- it's quite handy
>
> Perhaps we should add it. :)
my proposal is little b
* Erik Rijkers (e...@xs4all.nl) wrote:
> No need; that already does work, e.g.:
>
> testdb=# table pg_database limit 3;
Oh.
> Not in the documentation, but I hope it won't get removed -- it's quite handy
Perhaps we should add it. :)
Thanks!
Stephen
signature.asc
Desc
On Wed, February 13, 2013 21:23, Stephen Frost wrote:
> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
>> SELECT * FROM some_relation LIMIT 10
>>
>> what do you thinking about creating special statement for this purpose?
>
> I'd rather extend TABLE to support a limit clause or something.
>
No ne
2013/2/13 Stephen Frost :
> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
>> SELECT * FROM some_relation LIMIT 10
>>
>> what do you thinking about creating special statement for this purpose?
>
> I'd rather extend TABLE to support a limit clause or something.
??
Pavel
>
> Thanks,
>
>
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> SELECT * FROM some_relation LIMIT 10
>
> what do you thinking about creating special statement for this purpose?
I'd rather extend TABLE to support a limit clause or something.
Thanks,
Stephen
signature.asc
Description
Hello
probably one from my top ten SQL statement will be
SELECT * FROM some_relation LIMIT 10
what do you thinking about creating special statement for this purpose?
possible syntax
-- ViewTable
\vt table_name [rows]
or
\sample table_name [rows]
a implementation with autocomplete is terribl
30 matches
Mail list logo
