Bruce Momjian wrote:
OK, added to TODO:
Modify pg_get_triggerdef() to take a boolean to pretty-print,
and use that as part of pg_dump along with psql
Andreas, can you work on this? I like the idea of removing extra
parens, and merging it into the existing code rather than into co
Bruce Momjian wrote:
I don't think an option to do such justification would be good unless we
can do it consistenly in the code, and there is enough demand.
It's no big additional effort to do this, and going back and forth is
not a big problem. I wouldn't invent an option for that, just do it.
> SELECT foo
> FROM bar b
> LEFT JOIN chair c USING (thekeycol)
> WHERE ...
> :-)
Sub-selects are much nicer:
SELECT foo
, bar
, (SELECT anotherfoo
FROM tab2
WHERE tab2.col = tab1.col)
FROM tab
JOIN yet_another_table AS yat
ON
I don't think an option to do such justification would be good unless we
can do it consistenly in the code, and there is enough demand.
---
Andreas Pflug wrote:
> Rod Taylor wrote:
>
> >>Oh, one more thing --- right justify
Rod Taylor wrote:
Oh, one more thing --- right justify isn't as accepted as left-justify
But it looks so much better...
Ye!
Consider this:
SELECT foo
FROM bar b
LEFT JOIN chair c USING (thekeycol)
WHERE ...
:-)
versus
SELECT foo
FROM bar b
LEFT JOIN chair c USING (thekeycol)
WHE
> Oh, one more thing --- right justify isn't as accepted as left-justify
But it looks so much better...
--
Rod Taylor <[EMAIL PROTECTED]>
PGP Key: http://www.rbt.ca/rbtpub.asc
signature.asc
Description: This is a digitally signed message part
Andreas Pflug wrote:
> I also could implement line break and indentation formatting. I
> implemented a keyword-based algorithm in pgAdmin3, and having the
> original tree the job is obviously easier. Do we need any flexibility
> about indent char (tab or space) and indentation size (2 chars)? Th
Great. I recommend using spaces rather than tabs for indenting in psql
and pg_dump.
---
Andreas Pflug wrote:
>
>
> Bruce Momjian wrote:
>
> >OK, added to TODO:
> >
> > Modify pg_get_triggerdef() to take a boolean to
Bruce Momjian wrote:
OK, added to TODO:
Modify pg_get_triggerdef() to take a boolean to pretty-print,
and use that as part of pg_dump along with psql
Andreas, can you work on this? I like the idea of removing extra
parens, and merging it into the existing code rather than into
Add to TODO:
o Allow ALTER TABLE to modify column lengths and change to binary
compatible types
---
Tom Lane wrote:
> "Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> >> There might be other cases o
OK, added to TODO:
Modify pg_get_triggerdef() to take a boolean to pretty-print,
and use that as part of pg_dump along with psql
Andreas, can you work on this? I like the idea of removing extra
parens, and merging it into the existing code rather than into contrib
makes sense.
Tom Lane wrote:
Yes, you can check if they're binary compatible from the pg_cast table
But nearly all of the interesting cases require you to understand the
type's interpretation of typmod, and you can't learn that from a table.
How many cases are there where blindly looking for a binary-
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
>> There might be other cases of legal direct change of system catalog
>> entries, e,g. varchar to text, if they all are only names for internally
>> identical data structures. Can you tell which datatypes may be legally
>> interchanged?
> Y
> Right offhand I think text<->varchar and adjustment of length limits in
> char, varchar, and perhaps numeric would be the only things useful
> enough to worry about handling.
I'd love to have adding and removing precision and timezones on timestamp*
fields
Chris
---(en
> Hm, you're right, 'thou I wouldn't recommend this to the average user,
> and wonder if this will be possible for all future pgsql versions too.
> I'm considering adding safe support for this type of column change to
> pgAdmin3.
> There might be other cases of legal direct change of system cata
> If that's what you need you can always change the system catalogs
> manually. For CHAR(n) and VARCHAR(n) you change pg_attribute.atttypmod
> to (n+4). For NUMERIC(n,m) it's something like (n<<16) + m + 4 or maybe
> (m<<16) + n + 4, don't remember right now.
>
> Be sure to check that your data i
Andreas Pflug <[EMAIL PROTECTED]> writes:
> There might be other cases of legal direct change of system catalog
> entries, e,g. varchar to text, if they all are only names for internally
> identical data structures. Can you tell which datatypes may be legally
> interchanged?
Right offhand I thi
> There might be other cases of legal direct change of system catalog
> entries, e,g. varchar to text, if they all are only names for internally
> identical data structures. Can you tell which datatypes may be legally
> interchanged?
If pg_cast.castfunc is 0, you should might be able to do a da
Alvaro Herrera wrote:
On Wed, Jun 18, 2003 at 12:59:36PM +0200, Andreas Pflug wrote:
What I need again and again, is changing the size of a column (rarely
the type). For pgsql, I'd have to drop the column, and need to recreate
all views. For MSSQL, it won't matter if the column is dropped/re
On Wed, Jun 18, 2003 at 12:59:36PM +0200, Andreas Pflug wrote:
> What I need again and again, is changing the size of a column (rarely
> the type). For pgsql, I'd have to drop the column, and need to recreate
> all views. For MSSQL, it won't matter if the column is dropped/recreated
> or just r
Hi Christopher,
Sorry if I offended you.
I wasn't offended because I wasn't sure what you wanted to say to me.
You may call me the biggest fool of all, as long you do it in Sualheli,
or Korean... :-)
'You what!' is what you say when you cannot
believe what someone is saying... Calling 'stabl
Hi Andreas,
> I'm not natively english speaking, and so I don't understand what you
> want to say with this. Maybe this is some kind of Australian slang? Do
> you agree or disagree? I'm trying to explain my concerns and proposals,
> and it would be kind if I'm answered seriously and understandably
Christopher Kings-Lynne wrote:
this arguments are quite academic.
You what!
On one side, this could be
restricted, thats what pg_depends is good for (this already happens for
inherited tables).
On the other side, how often do you rename columns or tables?
You what!
On mssql, n
> this arguments are quite academic.
You what!
> On one side, this could be
> restricted, thats what pg_depends is good for (this already happens for
> inherited tables).
> On the other side, how often do you rename columns or tables?
You what!
> On mssql, nobody cares.
You what!
> If you
Rod Taylor wrote:
What I *really* want is having the original source stored, including
comments, version info, ... Currently, it's argued that underlying table
and column might change, braking the view/rule. This could be
restricted, or source could be dropped (alter table ... cascaded). Is it
> What I *really* want is having the original source stored, including
> comments, version info, ... Currently, it's argued that underlying table
> and column might change, braking the view/rule. This could be
> restricted, or source could be dropped (alter table ... cascaded). Is it
> really o
Tom Lane wrote:
I recall objecting to someone who wanted to remove "unnecessary"
parentheses, but I can't see any risk in inserting unnecessary
whitespace.
That "someone" was me indeed, and as I mentioned the code is completely
separated from the code that pg_dump uses. Thus, there's *no way* tha
Andreas Pflug <[EMAIL PROTECTED]> writes:
> Difference from Christopher's solution is that mine utilizes completely
> separatated (copied) code, so ruleutils code is still unchanged. This
> was a concession to Tom who claimed concerns about pg_dump not being
> able to reproduce things correctly
Christopher Kings-Lynne wrote:
We make pg_get_xxx2 functions that return a formatted version. Internally,
we just add an extra boolean parameter to the pg_get_triggerdef() function
in ruleutils and we call that true or false depending...
That's what I got too!
Several weeks ago I proposed such
> Seems like a good idea to me --- we've been trying to reduce pg_dump's
> knowledge of backend nitty-gritty, and this would be another small step
> in the right direction.
>
> > Also, it doesn't format them as nicely as the current pg_dump code...
>
> That's fixable no? I guess you might want to
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> Is there any point using pg_get_triggerdef in pg_dump to generate trigger
> definitions? We'd still have to keep the old code so that we can dump pre
> 7.4, but it might mean we don't have to touch that code again if we add
> triggers on colu
Is there any point using pg_get_triggerdef in pg_dump to generate trigger
definitions? We'd still have to keep the old code so that we can dump pre
7.4, but it might mean we don't have to touch that code again if we add
triggers on columns or something...
Also, it doesn't format them as nicely as
32 matches
Mail list logo
