2008/8/23 Tom Lane <[EMAIL PROTECTED]>:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
>> On Sat, 2008-08-23 at 08:21 +0200, Pavel Stehule wrote:
>>> record or hash table - it's implementation - second step. We have to
>>> find syntax and semantic now.
>
>> Why not just use some standard record syntax
On Sat, 23 Aug 2008 14:57:50 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
> Also, having now looked at the proposed patch, it seems clear that it
> isn't addressing the issue of quoting/escaping at all; so I wonder how
> this can be considered to be a safely machine-readable format.
It's not a machin
2008/8/24 daveg <[EMAIL PROTECTED]>:
> On Sat, Aug 23, 2008 at 05:08:25PM +0100, Gregory Stark wrote:
>> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
>>
>> > Hello
>> >
>> > 2008/8/23 Peter Eisentraut <[EMAIL PROTECTED]>:
>> >> On Friday 22 August 2008 07:41:30 Decibel! wrote:
>> >>> If we're really
On Sat, 23 Aug 2008 14:42:57 -0400
Andrew Dunstan <[EMAIL PROTECTED]> wrote:
> In general I think I prefer machine readable formats to be produces by
> the backend so they are available through all clients, not just psql.
What do you mean by "machine readable?" XML?
> That said, this has suffic
2008/8/23 Hannu Krosing <[EMAIL PROTECTED]>:
> On Sat, 2008-08-23 at 08:21 +0200, Pavel Stehule wrote:
>> Hello
>>
>> 2008/8/22 Hannu Krosing <[EMAIL PROTECTED]>:
>> > On Thu, 2008-08-21 at 23:41 -0500, Decibel! wrote:
>> >> On Aug 20, 2008, at 8:26 AM, Pavel Stehule wrote:
>> >
>> >> How about we
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I'm not sure all browsing setups support tooltips nicely.
> Any half way modern browser that is not text based should support tool tips.
Are we in the business of excluding text-based browsers? Or obsolete
ones, for that matter?
On Sat, Aug 23, 2008 at 05:08:25PM +0100, Gregory Stark wrote:
> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
>
> > Hello
> >
> > 2008/8/23 Peter Eisentraut <[EMAIL PROTECTED]>:
> >> On Friday 22 August 2008 07:41:30 Decibel! wrote:
> >>> If we're really worried about it we can have a GUC for a few
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Yes, I started on it. The problem is that we have very little real
estate available on the dashboard to display it. I tried making it
available as a tooltip but Tom didn't like that much (in private
correspondence), and I didn't get ba
Hannu Krosing <[EMAIL PROTECTED]> writes:
> On Sat, 2008-08-23 at 08:21 +0200, Pavel Stehule wrote:
>> record or hash table - it's implementation - second step. We have to
>> find syntax and semantic now.
> Why not just use some standard record syntax, like
> SELECT(value::type name, ...)
Yeah,
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Yes, I started on it. The problem is that we have very little real
> estate available on the dashboard to display it. I tried making it
> available as a tooltip but Tom didn't like that much (in private
> correspondence), and I didn't get back to doin
Alvaro Herrera wrote:
But maybe it would be nice to have some sort of "notes about this
buildfarm member" text field that contains this information (or other
stuff like "this is a VM running on bar" or "this is really the same
hardware as animal bar just with configuration baz" ?
>>
>> At any point in this discussion has anyone explained why these
>> labels would
>> actually be a good idea?
>>
>
> it's allows smart libraries like SQL/XML
You could always just pass the label as an additional parameter. Which
is all this would be syntactic sugar for anyways. So it doesn
D'Arcy J.M. Cain wrote:
On Thu, 21 Aug 2008 21:04:07 -0400
"D'Arcy J.M. Cain" <[EMAIL PROTECTED]> wrote:
There's still the question of whether this covers any needs that aren't
met just as well by XML or CSV output formats.
Well, we could remove all the display formats except XML.
> So for a bit of useless syntactic sugar we should introduce conflicts with
> named parameters, conflicts with operators, introduce an un-sqlish syntax and
> remove a feature users have already made use of and introduce backwards
> compatibility issues for those users?
>
we talk only about "=>" sy
2008/8/23 Tom Lane <[EMAIL PROTECTED]>:
> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
>> I thing, so it's possible - in this case. We should transform named
>> params to expr after syntax analyze.
>
> You're going to have a hard time making parentheses affect the behavior
> if you do it that way.
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Yes, I assumed we were following the recent work on ALTER TABLE/VIEW
> > with GRANT/REVOKE. Peter, Tom, how is GRANT/REVOKE different?
>
> GRANT/REVOKE behavior is specified by the standard, whereas the stuff
> we allow under ALTER V
Stefan Kaltenbrunner wrote:
> Tom Lane wrote:
>> Can you modify the buildfarm's description of that machine to mention
>> the special malloc debug flags? It'd probably stop me from asking
>> you this question again ;-)
>
> hmm - would take somebody with SQL-level access to do this - the script
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I think we should probably confine ourselves to output formats that are
> in very wide use or we'll be supporting a vast multitude. CSV and XML
> both qualify here - not sure that ReST does.
Yeah, that's the core of my objection.
Also, having now loo
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Peter Eisentraut wrote:
> >> On Tuesday 01 July 2008 01:39:13 Bruce Momjian wrote:
> >>> Is there a downside to adding "VIEW" in parser/gram.y:privilege_target?
> >>
> >> The SQL standard doesn't specify it. And there is no need for
Robert Haas wrote:
> >> While we don't _need_ it, it would make our system more consistent; we
> >> have made similar changes for views in other areas.
> >
> > I'm not sure it'd make the system more consistent. Because the SQL
> > standard says you use GRANT ON TABLE for a view. we'd have to alwa
On Sat, 2008-08-23 at 08:21 +0200, Pavel Stehule wrote:
> Hello
>
> 2008/8/22 Hannu Krosing <[EMAIL PROTECTED]>:
> > On Thu, 2008-08-21 at 23:41 -0500, Decibel! wrote:
> >> On Aug 20, 2008, at 8:26 AM, Pavel Stehule wrote:
> >
> >> How about we poll -general and see what people say? I'll bet Tom a
>> While we don't _need_ it, it would make our system more consistent; we
>> have made similar changes for views in other areas.
>
> I'm not sure it'd make the system more consistent. Because the SQL
> standard says you use GRANT ON TABLE for a view. we'd have to always
> ensure that we accepted
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Yes, I assumed we were following the recent work on ALTER TABLE/VIEW
> with GRANT/REVOKE. Peter, Tom, how is GRANT/REVOKE different?
GRANT/REVOKE behavior is specified by the standard, whereas the stuff
we allow under ALTER VIEW is all an extension to t
Bruce Momjian <[EMAIL PROTECTED]> writes:
> bruce wrote:
>> Tom Lane wrote:
>>> Currently, config.sgml still describes the new "enum" GUC variables
>>> as being of type "string" --- but pg_settings says they are "enum".
>>> This is not very consistent, but I wonder whether changing the docs
>>> wou
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> I thing, so it's possible - in this case. We should transform named
> params to expr after syntax analyze.
You're going to have a hard time making parentheses affect the behavior
if you do it that way.
regards, tom lane
--
S
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Peter Eisentraut wrote:
>> On Tuesday 01 July 2008 01:39:13 Bruce Momjian wrote:
>>> Is there a downside to adding "VIEW" in parser/gram.y:privilege_target?
>>
>> The SQL standard doesn't specify it. And there is no need for it.
> While we don't _need_
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> Hello
>
> 2008/8/23 Peter Eisentraut <[EMAIL PROTECTED]>:
>> On Friday 22 August 2008 07:41:30 Decibel! wrote:
>>> If we're really worried about it we can have a GUC for a few versions
>>> that turns off named parameter assignment. But I don't think we
On Sat, Aug 23, 2008 at 03:35:52PM +0900, Tatsuo Ishii wrote:
> > > Here is new patches fixing the bug you pointed out (patches was
> > > created by Yoshiyuki). Also I added your SQL to the regression
> > > test, and now the patches is against CVS HEAD. For your
> > > convenience I also include pat
Hello
2008/8/23 Peter Eisentraut <[EMAIL PROTECTED]>:
> On Friday 22 August 2008 07:41:30 Decibel! wrote:
>> If we're really worried about it we can have a GUC for a few versions
>> that turns off named parameter assignment. But I don't think we
>> should compromise the design on the theory that s
On Thu, 21 Aug 2008 21:04:07 -0400
"D'Arcy J.M. Cain" <[EMAIL PROTECTED]> wrote:
> > There's still the question of whether this covers any needs that aren't
> > met just as well by XML or CSV output formats.
>
> Well, we could remove all the display formats except XML. After all,
> it can always
Peter Eisentraut wrote:
> On Tuesday 01 July 2008 01:39:13 Bruce Momjian wrote:
> > Is there a downside to adding "VIEW" in parser/gram.y:privilege_target?
>
> The SQL standard doesn't specify it. And there is no need for it.
While we don't _need_ it, it would make our system more consistent; w
On Sat, 23 Aug 2008 14:04:30 +0400
Teodor Sigaev <[EMAIL PROTECTED]> wrote:
> >> select 'a'=>'b';
> >>?column?
> >> --
> >>"a"=>"b"
> "a"=>"b" is a value of hstore type, so query should be:
> select '"a"=>"b"'::hstore;
Of course. Now that I understand it's blindingly obvious that
On Tuesday 01 July 2008 01:39:13 Bruce Momjian wrote:
> Is there a downside to adding "VIEW" in parser/gram.y:privilege_target?
The SQL standard doesn't specify it. And there is no need for it.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscri
On Friday 22 August 2008 22:25:08 Bruce Momjian wrote:
> Peter, have you completed this yet?
yes
>
> ---
>
> Peter Eisentraut wrote:
> > Am Mittwoch, 9. Juli 2008 schrieb Peter Eisentraut:
> > > I propose that we relax these
On Friday 22 August 2008 07:41:30 Decibel! wrote:
> If we're really worried about it we can have a GUC for a few versions
> that turns off named parameter assignment. But I don't think we
> should compromise the design on the theory that some folks might be
> using that as an operator *and* c
select 'a'=>'b';
?column?
--
"a"=>"b"
Branching the topic, I have a question about this. I haven't studied
hstore extensively but this seems like a problem on it's face.
Shouldn't you be able to take the result of a select and pass it back
to a select? I mean, what happens if
36 matches
Mail list logo
