2013/2/3 Tom Lane :
> Pavel Stehule writes:
>> now missing variables is replaced by variable's name. We can implement
>> some pset option - some like define what do with missing variable
>
>> \pset missing_variable (use_name | use_null | error )
>
> No, it isn't "replaced by variable's name". Wha
Pavel Stehule writes:
> now missing variables is replaced by variable's name. We can implement
> some pset option - some like define what do with missing variable
> \pset missing_variable (use_name | use_null | error )
No, it isn't "replaced by variable's name". What actually happens is we
don'
2013/2/2 Tom Lane :
> Shigeru Hanada writes:
>> On Sat, Feb 2, 2013 at 7:30 PM, Pavel Stehule
>> wrote:
>>> possible variants
>>>
>>> a) don't store NULL values - and remove existing variable when NULL
>>> be assigned - it is probably best, but should be confusing for users
>>> b) implement fla
Pavel Stehule writes:
> 2013/2/2 Tom Lane :
>> Shigeru Hanada writes:
>>> +1 for a). If users want to determine whether the result was NULL, or
>>> want to use substitute string for NULL result, they can use coalesce
>>> in SELECT clause. Anyway the feature should be documented clearly.
>> Yea
Hello
2013/2/2 Tom Lane :
> Shigeru Hanada writes:
>> On Sat, Feb 2, 2013 at 7:30 PM, Pavel Stehule
>> wrote:
>>> possible variants
>>>
>>> a) don't store NULL values - and remove existing variable when NULL
>>> be assigned - it is probably best, but should be confusing for users
>>> b) implem
Shigeru Hanada writes:
> On Sat, Feb 2, 2013 at 7:30 PM, Pavel Stehule wrote:
>> possible variants
>>
>> a) don't store NULL values - and remove existing variable when NULL
>> be assigned - it is probably best, but should be confusing for users
>> b) implement flag IS NULL - for variables
>> c)
2013/2/2 Shigeru Hanada :
> On Sat, Feb 2, 2013 at 7:30 PM, Pavel Stehule wrote:
>> possible variants
>>
>> a) don't store NULL values - and remove existing variable when NULL
>> be assigned - it is probably best, but should be confusing for users
>> b) implement flag IS NULL - for variables
>> c
On Sat, Feb 2, 2013 at 7:30 PM, Pavel Stehule wrote:
> possible variants
>
> a) don't store NULL values - and remove existing variable when NULL
> be assigned - it is probably best, but should be confusing for users
> b) implement flag IS NULL - for variables
> c) use nullPrint
> d) use empty Str
Hello
2013/2/1 Tom Lane :
> Pavel Stehule writes:
>> here is patch related to your proposal
>
> I looked at this a bit. It's getting there, though I still don't trust
> the places where you've chosen to clear the prefix setting. (Looking at
> it, I'm now not sure that I trust the implementation
Pavel Stehule writes:
> here is patch related to your proposal
I looked at this a bit. It's getting there, though I still don't trust
the places where you've chosen to clear the prefix setting. (Looking at
it, I'm now not sure that I trust the implementation of \g either.)
However, what I want
Hello
can you look, please, on updated version - it respects Tom's proposal
and it is significantly reduced?
Thank you
Pavel Stehule
2013/1/28 Pavel Stehule :
> Hello
>
> 2013/1/26 Tom Lane :
>> Andrew Dunstan writes:
>>> +1. This looks quite nifty. Maybe useful too to have a default prefix
>>
Hello
2013/1/26 Tom Lane :
> Andrew Dunstan writes:
>> +1. This looks quite nifty. Maybe useful too to have a default prefix
>> via some setting.
>
> Meh. I would expect that "\gset :foo" would work to specify a computed
> prefix if you wanted it --- isn't that sufficient indirection? I'm not
>
Hello
2013/1/26 Tom Lane :
> I wrote:
>> Pavel Stehule writes:
>>> [ gset_13.diff ]
>
>> One more gripe is that the parsing logic for \gset is pretty
>> unintelligible.
>
> After further thought, it seems to me that the problem here is an
> overcomplicated definition of the \gset command; it coul
Andrew Dunstan writes:
> +1. This looks quite nifty. Maybe useful too to have a default prefix
> via some setting.
Meh. I would expect that "\gset :foo" would work to specify a computed
prefix if you wanted it --- isn't that sufficient indirection? I'm not
thrilled with further expanding the s
On 01/26/2013 11:42 AM, Tom Lane wrote:
A probably-useful extension to this basic concept is to allow \gset
to specify an optional prefix, that is
select 1 as x, 2 as y \gset p_
would set p_x and p_y. This would make it easier to manage results from
multiple \gset operations, and to be
I wrote:
> Pavel Stehule writes:
>> [ gset_13.diff ]
> One more gripe is that the parsing logic for \gset is pretty
> unintelligible.
After further thought, it seems to me that the problem here is an
overcomplicated definition of the \gset command; it could be made
both more usable and simpler t
Pavel Stehule writes:
> [ gset_13.diff ]
I looked at this a bit. I think you need to reconsider when and how the
\gset state gets cleaned up. Doing it inside StoreQueryResult is not
very good because that only gets reached upon successful execution.
Consider for example
select 1/0 \gse
2012/12/19 Shigeru Hanada :
> On Tue, Dec 18, 2012 at 2:52 AM, Pavel Stehule
> wrote:
>> Attached updated patch
>
> Seems fine. I'll mark this as "ready for committer".
>
> Nice work!
thank you very much
Regards
Pavel
>
> --
> Shigeru HANADA
--
Sent via pgsql-hackers mailing list (pgsql-h
On Tue, Dec 18, 2012 at 2:52 AM, Pavel Stehule wrote:
> Attached updated patch
Seems fine. I'll mark this as "ready for committer".
Nice work!
--
Shigeru HANADA
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql
2012/12/17 Shigeru Hanada :
> On Sun, Oct 28, 2012 at 7:16 AM, Pavel Stehule
> wrote:
>> Hello
>>
>> here is updated patch
>>
>> main change - it doesn't touch psql lexer - like Tom proposed
>> other points respect Phil's notices
>
> I reviewed v12 patch. It provides gset command which works
> c
On Sun, Oct 28, 2012 at 7:16 AM, Pavel Stehule wrote:
> Hello
>
> here is updated patch
>
> main change - it doesn't touch psql lexer - like Tom proposed
> other points respect Phil's notices
I reviewed v12 patch. It provides gset command which works
consistently with other psql commands, such a
Hello
here is updated patch
main change - it doesn't touch psql lexer - like Tom proposed
other points respect Phil's notices
>>
>
> My first review...
>
> Patch applied cleanly to master and make check was fine.
>
> I tested it out and it operates as advertised. There were a couple
> things th
Hello
>
> My first review...
>
> Patch applied cleanly to master and make check was fine.
>
> I tested it out and it operates as advertised. There were a couple
> things that stood out to me though.
>
> 1) NULL values are not displayed properly after \pset null is run.
>
> postgres=# \pset null '(
2012/10/25 Tom Lane :
> Pavel Stehule writes:
>> 2012/10/25 Tom Lane :
>>> Personally I saw no reason for this patch to touch psqlscan.l in the
>>> first place. Commands such as \set just scan variable names with
>>> psql_scan_slash_option(OT_NORMAL); why shouldn't this act the same?
>
>> it cann
Pavel Stehule writes:
> 2012/10/25 Tom Lane :
>> Personally I saw no reason for this patch to touch psqlscan.l in the
>> first place. Commands such as \set just scan variable names with
>> psql_scan_slash_option(OT_NORMAL); why shouldn't this act the same?
> it cannot be same, because current sc
2012/10/25 Tom Lane :
> Alvaro Herrera writes:
>> I gave this a look. I think it needs to be revised by somebody with a
>> better understanding of scanner (flex) than me, but I didn't like the
>> changes in psqlscan.l at all; the new pattern is too unlike the
>> rest of the surrounding patterns,
Tom Lane escribió:
> Alvaro Herrera writes:
> > I gave this a look. I think it needs to be revised by somebody with a
> > better understanding of scanner (flex) than me, but I didn't like the
> > changes in psqlscan.l at all; the new pattern is too unlike the
> > rest of the surrounding patterns
Alvaro Herrera writes:
> I gave this a look. I think it needs to be revised by somebody with a
> better understanding of scanner (flex) than me, but I didn't like the
> changes in psqlscan.l at all; the new pattern is too unlike the
> rest of the surrounding patterns, and furthermore it has been
I gave this a look. I think it needs to be revised by somebody with a
better understanding of scanner (flex) than me, but I didn't like the
changes in psqlscan.l at all; the new pattern is too unlike the
rest of the surrounding patterns, and furthermore it has been placed
within the block that sa
On Tue, Oct 16, 2012 at 12:24 PM, Pavel Stehule wrote:
> 2012/10/16 Shigeru HANADA :
>> Hi Pavel,
>>
>> On Tue, Oct 16, 2012 at 6:59 AM, Pavel Stehule
>> wrote:
>>> here is updated patch, I moved lot of code from lexer to command.com,
>>> and now more \gset doesn't disable other backslash command
2012/10/16 Shigeru HANADA :
> Hi Pavel,
>
> On Tue, Oct 16, 2012 at 6:59 AM, Pavel Stehule
> wrote:
>> here is updated patch, I moved lot of code from lexer to command.com,
>> and now more \gset doesn't disable other backslash commands on same
>> line.
>
> * lexer changes
> IIUC, new function psql
Hello
here is updated patch, I moved lot of code from lexer to command.com,
and now more \gset doesn't disable other backslash commands on same
line.
Regards
Pavel
2012/10/15 Pavel Stehule :
> 2012/10/15 Pavel Stehule :
>> 2012/10/15 Shigeru HANADA :
>>> Hi Pavel,
>>>
>>> First of all, I'm sorr
Hi Pavel,
On Tue, Oct 16, 2012 at 6:59 AM, Pavel Stehule
wrote:
> here is updated patch, I moved lot of code from lexer to command.com,
> and now more \gset doesn't disable other backslash commands on same
> line.
* lexer changes
IIUC, new function psql_scan_varlist_varname scans input and retur
2012/10/15 Pavel Stehule :
> 2012/10/15 Shigeru HANADA :
>> Hi Pavel,
>>
>> First of all, I'm sorry that my previous review was rough. I looked
>> your patch and existing code closely again.
>>
>> On 2012/10/15, at 12:57, Pavel Stehule wrote:
>>> 2012/10/14 Tom Lane :
* ExecQueryUsingCursor'
2012/10/15 Shigeru HANADA :
> Hi Pavel,
>
> First of all, I'm sorry that my previous review was rough. I looked
> your patch and existing code closely again.
>
> On 2012/10/15, at 12:57, Pavel Stehule wrote:
>> 2012/10/14 Tom Lane :
>>> * ExecQueryUsingCursor's concept of how to process command r
Hi Pavel,
First of all, I'm sorry that my previous review was rough. I looked
your patch and existing code closely again.
On 2012/10/15, at 12:57, Pavel Stehule wrote:
> 2012/10/14 Tom Lane :
>> * ExecQueryUsingCursor's concept of how to process command results
>> (why? surely we don't need \g
2012/10/15 Pavel Stehule :
> Hello
>
> 2012/10/14 Tom Lane :
>> Pavel Stehule writes:
>>> [ gset_08.diff ]
>>
>> In the course of adding a new backslash command, this patch manages to
>> touch:
>>
>> * the main loop's concept of what types of backslash commands exist
>> (PSQL_CMD_NOSEND ... what
Hello
2012/10/14 Tom Lane :
> Pavel Stehule writes:
>> [ gset_08.diff ]
>
> In the course of adding a new backslash command, this patch manages to
> touch:
>
> * the main loop's concept of what types of backslash commands exist
> (PSQL_CMD_NOSEND ... what's the point of that, rather than making
Hello
fast reply
2012/10/14 Tom Lane :
> Pavel Stehule writes:
>> [ gset_08.diff ]
>
> In the course of adding a new backslash command, this patch manages to
> touch:
>
> * the main loop's concept of what types of backslash commands exist
> (PSQL_CMD_NOSEND ... what's the point of that, rather
Pavel Stehule writes:
> [ gset_08.diff ]
In the course of adding a new backslash command, this patch manages to
touch:
* the main loop's concept of what types of backslash commands exist
(PSQL_CMD_NOSEND ... what's the point of that, rather than making
this work the same as \g?)
* SendQuery'
Hi Pavel,
On Sat, Oct 13, 2012 at 12:58 AM, Pavel Stehule
wrote:
* merge Shigeru's doc patch
* rename psql regression test from "psql" to "psql_cmd"
Those changes seem good.
Besides, I found an error message which doesn't end with '¥n' in
common.c. In general, messages passed to psql_erro
Hello
2012/10/14 Erik Rijkers :
> On Sat, October 13, 2012 19:26, Pavel Stehule wrote:
>> 2012/10/13 Shigeru HANADA :
>>> After you determine whether it's ok or unnecessary, I'll mark this patch as
>>> "Ready for committer".
>>>
>>
>
> I found this behaviour which I think must count as a bug.
> \g
On Sat, October 13, 2012 19:26, Pavel Stehule wrote:
> 2012/10/13 Shigeru HANADA :
>> After you determine whether it's ok or unnecessary, I'll mark this patch as
>> "Ready for committer".
>>
>
I found this behaviour which I think must count as a bug.
\gset doesn't allow more \\-separated lines beh
2012/10/13 Shigeru HANADA :
> Hi Pavel,
>
>
> On Sat, Oct 13, 2012 at 12:58 AM, Pavel Stehule
> wrote:
>>
>> * merge Shigeru's doc patch
>> * rename psql regression test from "psql" to "psql_cmd"
>
>
> Those changes seem good.
>
> Besides, I found an error message which doesn't end with '¥n' in co
Hello
here is updated version of gset patch.
* merge Shigeru's doc patch
* rename psql regression test from "psql" to "psql_cmd"
Regards
Pavel Stehule
2012/9/27 Pavel Stehule :
> Hello
>
> 2012/9/21 Shigeru HANADA :
>> Hi Pavel,
>>
>> (2012/09/21 2:01), Pavel Stehule wrote:
- Is it inten
Hello
2012/9/21 Shigeru HANADA :
> Hi Pavel,
>
> (2012/09/21 2:01), Pavel Stehule wrote:
>>> - Is it intentional that \gset can set special variables such as
>>> AUTOCOMMIT and HOST? I don't see any downside for this behavior,
>>> because \set also can do that, but it is not documented nor tested
Hi Pavel,
(2012/09/21 2:01), Pavel Stehule wrote:
>> - Is it intentional that \gset can set special variables such as
>> AUTOCOMMIT and HOST? I don't see any downside for this behavior,
>> because \set also can do that, but it is not documented nor tested at all.
>>
>
> I use a same "SetVariable
Hello
2012/9/19 Shigeru HANADA :
> On Fri, Aug 10, 2012 at 3:21 AM, Pavel Stehule
> wrote:
>> there is new version of this patch
>>
>> * cleaned var list parser
>> * new regress tests
>> * support FETCH_COUNT > 0
>
> Here are my review comments.
>
> Submission
> ==
> The patch is formatte
On Fri, Aug 10, 2012 at 3:21 AM, Pavel Stehule
wrote:
> there is new version of this patch
>
> * cleaned var list parser
> * new regress tests
> * support FETCH_COUNT > 0
Here are my review comments.
Submission
==
The patch is formatted in context diff style, and it could be applied
clea
Hello
there is new version of this patch
* cleaned var list parser
* new regress tests
* support FETCH_COUNT > 0
Regards
Pavel Stehule
2012/8/1 David Fetter :
> On Sat, Jul 28, 2012 at 06:11:21PM +0200, Pavel Stehule wrote:
>> Hello
>>
>> 2012/7/27 Tom Lane :
>> > Pavel Stehule writes:
>> >>
On Sat, Jul 28, 2012 at 06:11:21PM +0200, Pavel Stehule wrote:
> Hello
>
> 2012/7/27 Tom Lane :
> > Pavel Stehule writes:
> >> 2012/7/26 David Fetter :
> > How about
> > \gset var1,,,var2,var3...
> >
> I don't like this - you can use fake variable - and ignoring some
> variable
Hello
2012/7/27 Tom Lane :
> Pavel Stehule writes:
>> 2012/7/26 David Fetter :
> How about
> \gset var1,,,var2,var3...
>
I don't like this - you can use fake variable - and ignoring some
variable has no big effect on client
>
>>> Why assign to a variable you'll never use?
>
>> s
Pavel Stehule writes:
> 2012/7/26 David Fetter :
How about
\gset var1,,,var2,var3...
>>> I don't like this - you can use fake variable - and ignoring some
>>> variable has no big effect on client
>> Why assign to a variable you'll never use?
> so why you get data from server, when you
2012/7/26 David Fetter :
> On Thu, Jul 26, 2012 at 08:31:13AM +0200, Pavel Stehule wrote:
>> 2012/7/26 David Fetter :
>> > On Thu, Jul 26, 2012 at 01:36:17AM -0400, Tom Lane wrote:
>> >> Pavel Stehule writes:
>> >> > \eset variable [, variable [..]] query -- it raise exception when
>> >> > more t
On Thu, Jul 26, 2012 at 08:31:13AM +0200, Pavel Stehule wrote:
> 2012/7/26 David Fetter :
> > On Thu, Jul 26, 2012 at 01:36:17AM -0400, Tom Lane wrote:
> >> Pavel Stehule writes:
> >> > \eset variable [, variable [..]] query -- it raise exception when
> >> > more than one row is returned or when
2012/7/26 David Fetter :
> On Thu, Jul 26, 2012 at 01:36:17AM -0400, Tom Lane wrote:
>> Pavel Stehule writes:
>> > \eset variable [, variable [..]] query -- it raise exception when
>> > more than one row is returned or when no row is returned
>>
>> Better would be a variant on \g, that is you typ
On Thu, Jul 26, 2012 at 01:36:17AM -0400, Tom Lane wrote:
> Pavel Stehule writes:
> > \eset variable [, variable [..]] query -- it raise exception when
> > more than one row is returned or when no row is returned
>
> Better would be a variant on \g, that is you type in the query and
> then tell
2012/7/26 Tom Lane :
> Pavel Stehule writes:
>> \eset variable [, variable [..]] query -- it raise exception when
>> more than one row is returned or when no row is returned
>
> Better would be a variant on \g, that is you type in the query and
> then tell it where to put the result. We have lea
Pavel Stehule writes:
> \eset variable [, variable [..]] query -- it raise exception when
> more than one row is returned or when no row is returned
Better would be a variant on \g, that is you type in the query and
then tell it where to put the result. We have learned the hard way
that putting
Hello
we cannot actually store result of query to psql variable
I propose a new slash statement "\eset for this purpose
Syntax:
\eset variable [, variable [..]] query -- it raise exception when
more than one row is returned or when no row is returned
Usage:
\eset var1, var2 select version(),
60 matches
Mail list logo
